You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
For discussion: What to do when GPS data for OSM data is inaccurate #160
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?
@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.
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.
@mberghttps://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.
Activity
dalekunce commentedon Sep 27, 2016
@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 commentedon 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:
hallahan commentedon Sep 28, 2016
The move feature is already there. When you select a node, look at the button in the upper right.