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

For discussion: What to do when GPS data for OSM data is inaccurate #160

Open
mberg opened this issue Sep 26, 2016 · 3 comments
Open

For discussion: What to do when GPS data for OSM data is inaccurate #160

mberg opened this issue Sep 26, 2016 · 3 comments

Comments

@mberg
Copy link

mberg commented Sep 26, 2016

We're starting to come across an important implementation issue with OMK. If you want to use OMK to validate say water points for example, you might find that the original GPS point used to generate the OSM file can be quite in accurate. Ie) 50-100M off. Once you are in the field and you properly identify the point you have an important opportunity to correct/improve the accuracy of the point.

Currently, OMK doesn't really provide an elegant way of handling this. If you click on the point, you are validating the old inaccurate GPS. Deleting and adding a new point isn't ideal as you lose a lot of meta data.

To solve this, we could potentially add a "move feature". For nodes, it would allow you to move the marker to your current location. Ways are obviously more complicated. One option could be to have your current location become the centroid for the polygon. You would probably want to be able to rotate the shape though to ensure it's retains proper orientation. Being able to move the position of the node or way is also probably useful too.

We could potentially put some resources into helping implement this. It would be good to get some community discussion and agreement on how to tackle this. Curious to see too if anyone has any clever work arounds?

@dalekunce
Copy link

@mberg these are all good points. Our existing workflow is to load the data into either iD or JOSM and then fix the geometry. We don't need another editor and I would prefer we take advantage of the existing editors, albeit tied more closely into the OMK workflow.

@mberg
Copy link
Author

mberg commented Sep 27, 2016

I'm not suggesting we would want to edit the polygons in OMK. I agree an
external editor is much better for that type of cleanup.

We still need a way of capturing though that the point if off in the
field. For a node I think being able to overwrite the lat long with a new
location (similar UI to adding a new node could make sense. For polys
maybe we can have a tag we use for indicating there is a requested move and
you had the ability to add a GPS point representing the proposed centroid.
This could then be used to correct things in josm or Id.

Being able to correct nodes simply in the field though in scenarios where
you want to validate existing service points.

On Sep 27, 2016 10:49 PM, "Dale Kunce" notifications@github.com wrote:

@mberg https://github.com/mberg these are all good points. Our existing
workflow is to load the data into either iD or JOSM and then fix the
geometry. We don't need another editor and I would prefer we take advantage
of the existing editors, albeit tied more closely into the OMK workflow.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADiQbTH6wPrlwz8BvdszLj8Do2jjMwQks5quY99gaJpZM4KGblu
.

@hallahan
Copy link
Contributor

The move feature is already there. When you select a node, look at the button in the upper right.

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

3 participants