More Problems
1) Source
.. the source tags can be in the relation and not the way ...
Change the way to the new source and yet the other relations all say it is some
other source.
My conclusion is that the source should be on the way.
2)
Are the other relations, that refer to this way, that are being changed by the
new source ok with this change?
3)
You are going to have to compare each new outline with the old outlines ..
Where they are the same (or within, say, 3 metres) then leave the old way there
and mark it checked=new source + date
(the 3 metres comes from the JOSM simplify way set to a default of 3 metres,
I'd use the same level of accuracy here)
4)
Where the boundary lies along a waterway for some distance .. I would tend not
to join them.
The water course can change over time, the boundary is usually set not to
follow changes in the water course.
On 19-Feb-17 03:52 PM, nwastra wrote:
…..Actually, all the overlapping ways in the current shapefile are where
adjacent relations meet.
On 19 Feb 2017, at 2:04 PM, nwastra <nwas...@gmail.com> wrote:
Hi
is there a JOSM plugin to assist with duplicate ways?
We have been given explicit permission to use a good data set of shapefiles
that define boundaries for the OSM.
Using JOSM, my method is to select the shapefile relation for a particular
National Park for instance then merge the selection into the OSM Data Layer.
Often a replace geometry is needed on many polygons to help preserve the
history. Add all the tags to the relation.
Then the hard part….
You have to cut up and conflate the new boundaries with the existing data.
All the duplicate overlying ways need to be selected, nodes entered, nodes
merged and joined at the end, boundary and nodes selected where split is
performed, remove extra over lapping ways to generally leave one, add that one
left to this or another relation. Add more tags as needed.
Then selection each relation that was affected and view the result to see if it
is complete.
In some areas there are likely to be National Parks and other protected areas,
forestry areas, etc all adjacent to each other with boundaries that meet.
Another method I use is to split up the relation before merging piece by piece
but is just as complex.
Another method is to leave the overlapping ways for someone else to sort out.
In some relations there may be 30 or so adjacent polygons with ways partially
overlapping so is a lot of work that I think would be ideal for plugin
assistance and efficiency.
It seems to me that if one relation is selected at a time, it should be a task
able to be mostly automated by programming. Then it would be up to the mapper
to verify and quality control the result.
I am a new user to QGis and wonder if the splitting and conflating of the
shapefile to be merged can be done in QGis prior to introduction to JOSM and
then would only need to sort out areas between adjacent relations.
Is it best not to bother doing this anyway or even preferable to leave all the
polygons as individual entities with overlapping ways?
Finally, I should add that I do try to add small discreet areas and relations
one at a time that are manageable before proceeding.
Nev
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
