OsmSplitter class issue | Planet Community

Hi Sinergise,

Find below a screenshot of an unexpected OsmSplitter output:

I used zoom_level=12 as a parameter, but I see there are gaps between the generated output, whereas an OSM grid should not have any gaps. I tried to look into the source code but I cannot seem to spot the problem, so I was thinking that it may be due to a decimal rounding problem when dividing the latitude and longitude recursively to get to the specified zoom level.

Let me know what you can find out. In the meantime I am not blocked, I am using the OSM grid through the CustomGridSplitter to get a gapless grid.

Regards,

Page 1 / 1

Hi,

Thanks for pointing it out, we will have a look.

Could you just tell me what was your “workflow”? Any transformations of geometries done before you’ve passed it to OsmSplitter?

Best,

You are right, performing it as per example using CRS.WGS84 works.

I am wondering now if it makes sense to remove the CRS as input for OsmSplitter, and on-the-fly reproject to WGS84 inside the OsmSplitter class, whatever the input CRS may be, since it is the only projection for which the splitter can function. Allowing it to be passed as parameter is therefore not necessary.

Other splitter (at least BboxSplitter) functions can handle different CRS, namely UTM which I use to do the processing in the native sentinel imagery format (so as to avoid reprojecting the thousands of Sentinel imagery patches used as input), so the input CRS parameter should be maintained for those methods.

Regards,