0

I'm attempting to render continental geometric data stored within an R-Tree in a SQlite database. The data is store as long/lat WGS84 and I'm trying to render it to 256px PNGs for displaying on a slippy map. Keep in mind I have no training in GIS mapping and rendering and everything I know is self taught.

When I render it using OpenGL, I'm simply remapping the long/lat coordinates of each of the polygons returned from the SQLite query into a 0px to 256px x/y coordinate space for rendering on a slippy map tile using the following code:

X = (long - extent.X1) / (extent.X2 - extent.X1) * ImageSize;
Y = (((lat - extent.Y1) / (extent.Y2 - extent.Y1) * ImageSize) *-1) + ImageSize;

For the Y coordinate, I'm switching the axis so that 0:0 is the top left of the image.

The extent information in the above code is built by taking X/Y and Zoom data from a slippy map (leaflet.js in this case) and converted into long/lat bounds using the code provided by OSM here

Thats all I do before I send the X & Y data over to OpenGL.

At the higher zoom levels (5+). The polygons render okay, heres Australia at zoom level 5 (there are 1 or 2 exceptions around the equator where there are some glitches at zoom level 5, but they seem to completely disappear at zoom levels 6+):

enter image description here

However, at zoom levels below 5, things start to go hay wire, here's Australia and South Asia at zoom level 3:

enter image description here

There are significant glitches in the rendering, (repetition and misalignment with the rendered polygons on the tiles and stretching of the continents) And it only gets worse as I zoom out more. Here's part of the map at zoom level 2:

enter image description here

It seemed weird to me that everything would render well at the higher zoom levels but fail so badly at the lower ones. But then it occurred to me that the closer to earth I go, the flatter (and more 2D like) it becomes, so I'm now wondering if the reason for the major issues I'm having is because I'm not projecting to a Cartesian coordinate system first.

Can anyone confirm whether this is the case and if so, what should I be using to convert the coordinates from WGS84 to Cartesian X/Y?

Improve this question
2
  • That was it! Thanks @TurePålsson I actually found bboxfinder.com (which looks like it draws from OSM) to align the tile names with the correct bounding box and noticed the code I got from OSM for converting from XYZ to long/lat bounds was actually returning the wrong bounding box values and when I dug into it, I saw I wasn't sending in the right XYZ values to align the bbox with 256 pixel images. I fixed it up and now it renders perfectly. Silly mistake. But go ahead and move your comment to an answer and will mark it as the correct one. Thanks again!
    – Walter
    Commented Oct 28, 2019 at 13:16
  • I moved the comment to an answer and fixed some language problems in the move. :)
    – Ture Pålsson
    Commented Oct 28, 2019 at 13:22

1 Answer 1

Reset to default
1

So effecively you are interpolating coordinates linearly across the tiles. Unless I'm overlooking something, that might give you some wonky shape distortions at smaller scales (more zoomed out), but it should not give the kind of effects that you are seeing. If you are using the same tile numering scheme as OSM, you could try comparing one of your tiles from zoom level 2 with the same-numbered tile from one of the OSM tile servers. They should show the same area. If they don't, then your tile numbering is off.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.