-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offset for imagery #175
Comments
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?
In the slippy map dir should do the trick. |
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.
The text was updated successfully, but these errors were encountered: