Marker Positioning Logic about tileview

[moagrius]

Hey @brenton-crowley,

As regards the documentation of the signature of define bounds, the signature is defineRelativeBounds(double left, double top, double right, double bottom), which calls PositionManager's public void setBounds( double l, double t, double r, double b ) - my "eg" in the documentation is incorrect - I'll remove next time.

As far as positioning, it's actually pretty basic, and not at all based on geolocation. It just uses a relative point. If you define bounds between 0 and 1, then use a positioning method and pass a value of 0.4, the pixel returned would be 40% of the total axis (width or height, depending on if the 0.4 was for X or Y). So if you define the bounds with latitudes of 45.1250 through 45.6725, it would calculate that 45.39875 would be the vertical halfway point. I suspect that true geolocation wouldn't be as simple, and that the curve of the planet's surface would need to considered, but I think only rarely would this have a visible effect.

The class that does the position translation is PositionManager, and the signature is translate - here's what's actually happening.

The demo is kind of cobbled together from a (very) old version of this widget (2 years?) that did use Boston coordinates, but I could very well have changed them for debugging purposes, or tweaked the corner coordinates, etc. As I said, the positioning methods just take the relative point you supply and multiply that against the dimensions you supply to come back with a pixel position - there's no actual geolocation happening. The original widget did use lat/lng, and the basic relative positioning approach used by TileView, and it was at least close enough so that the markers did line up visually.

I suppose it's possible there's some bad math laying around in there - now that you understand what's happening with positioning, feel free to post back if you discover a problem.

HTH, and thanks for the input.

Mike

[brenton-crowley]

Hi @moagrius,

I looked a little more beneath the hood and it turns out we are using the same positioning logic (relating to the iOS version I created).

I have identified the problem, and having identified it, the existing documentation now makes much more sense.

The relative position logic translates to x, y positions. This is fine in normal circumstances, but in relation to coordinates things get a little more funky. The conventional way to refer to coordinates is the form:

coordinate(latitude, longitude);

but in a screen environment latitude values correspond to y-values and longitude to x-values. If I were to follow the original documentation and define my bounds as such:

defineRelativeBounds(long, lat, long, lat);

then wherever I add a marker it must also follow this same convention.

addMarker(longitude, latitude);

In the examples provided, the inputted are around the wrong way (lat, long). I will continue with your existing implementation, but perhaps you could update the demo and docs to notify the developer that coordinates should be in the form of (long, lat).

Or perhaps a convenience method could be inserted for adding a marker at a coordinate, and then the tileView can take care of switching the values around. Ultimately, it should reflect the same pattern as the defineRelativeBounds().

tileView.addMarkerAtCoordinate(view, lat, long);

I hope that I made some sense :)

[moagrius]

I had hoped to remove all notion of convention when switching from "faux-geolocation" to "relative positioning", and not making any mention of lat/lng, but I agree that you're right, what few references remain are more confusing and should be removed from the documentation. I'll leave this issue open until I get a chance to do that.

[brenton-crowley]

Great. Thanks for the clarification.

[moagrius]

docs have been updated to remove inconsistent references. thanks for contributing. closing issue now.