Skip to content
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

Closed
james2432 opened this issue Jul 18, 2019 · 6 comments
Closed

Offset for imagery #175

james2432 opened this issue Jul 18, 2019 · 6 comments

Comments

@james2432
Copy link

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.

@daniel-j-h
Copy link
Collaborator

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.

@james2432
Copy link
Author

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

@daniel-j-h
Copy link
Collaborator

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.

@james2432
Copy link
Author

james2432 commented Jul 18, 2019

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):

image

But with a offset to the imagery it can look like this:
image

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

@daniel-j-h
Copy link
Collaborator

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.

@daniel-j-h
Copy link
Collaborator

Closing here as not actionable on our end. I'd like to keep robosat free from arbitrary transformations on satellite imagery or GeoJSON features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants