Closed james2432 closed 4 years ago
Hey thanks for the feedback.
If you know the offset why not using e.g. gdal to align the imagery to the OpenStreetMap labels? You want to align anyway for the resulting map, no? I don't think we should encode this in our model.
Sometimes you don't own the imagery server such as the ESRI World Imagery server and unless you are downloading the tiles individually and rehosting it, it would be a pain to do it with gdal
Can you do it on the fly e.g. like this proxy https://github.com/mapbox/whoots-js?
We have to dowload the tiles anyway to work with their slippy map representation. Not sure I follow here. Rehosting can be as simple as starting a local http server and pointing rs download to it, no?
python3 -m http.server
In the slippy map dir should do the trick.
Correct me if I'm wrong here wms encodes the left top most corner with a certain value (z x y)
So with the current process the wms and openstreetmap data looks and aligns like this(if you say have ground truthed <1cm precision building data):
But with a offset to the imagery it can look like this:
So this would be during the download of the imagery it could affect the folders/images to substract/add the offset to the z/x/y? After that nothing else would have to be done as the coordinates would be corrected
I see what you mean now.
Maybe in this specific case it's easier to apply the offset to the extracted GeoJSON files directly? Assuming your offset is the same for all features. You could then work on the GeoJSON features, use e.g. shapely to do geometric transformations, and write out new GeoJSON files again.
Closing here as not actionable on our end. I'd like to keep robosat free from arbitrary transformations on satellite imagery or GeoJSON features.
Some satellite imagery doesn't line up with real world/ground truth and require the imagery to have an offset. Having support for specifying a known offset could help the neural network train more accurately.