Hi, Andrew:
Thank you for your feedback.
Some further comments inline:
On 23/10/18 02:58, Andrew Harvey wrote:
Thanks for reviewing this Rafael.
On Mon, 22 Oct 2018 at 22:52, Rafael Avila Coya <[email protected]> wrote:
I've been looking only a bit inside the data (file 1.osm) and I have
some issues/questions:
Running the JOSM validator, it throws the following errors and warnings:
Errors:
2,384 duplicated way nodes.
864 intersection between multipolygon ways.
40 multipoligon members repeated with same role (they seem to be
duplicated nodes as well)
And 1 way contains twice a segment.
Warnings:
43,708 crossing boundaries
3 overlapping ways
15 self-crossing ways
1,156 self-intersecting polygon rings, and
51 self-intersecting ways
All these errors and warnings should be fixed before importing, and you
should document how you will proceed to fix them in the import wiki.
Some of these are fixed in the simplified files.
As for the simplified file of 1.osm, you are completely right: only
warnings of 55 crossing boundaries, and 19 to-be-ignored long segment
boundaries. I should have checked that file too, but I wrongly thought
that most of errors and warnings would be there too...
However:
Error: Multipolygon member(s) repeated with same role
Error: Intersection between multipolygon ways - same as above
Warning: Crossing boundaries
All of these are most likely due to the original geometries being out
by around 0.1m so they aren't being snapped by the processing scripts,
I'll need to see if we can increase the tolerance to ensure these get
automatically snapped together to avoid these geometry issues.
If the numbers are like the ones in 1.osm (55 crossing ways), you may
consider doing it by hand. Not a big job I think.
The other warnings:
Long Segments - I'm not sure why we can't have long ways, I'm okay to
ignore this.
That's why I didn't mention them in my email ;)
Yes, I guess you can safely ignore those warnings.
Relations with same members - This is expected, we can have an
admin_level 10 and admin_level 6 which are the same hence two
relations with the same members.
I didn't mention that a two or more relation can share an object as
member. This happens very often and it's completely normal.
The "40 multipoligon members repeated with same role" means that a
relation has an object two or more times repeated as member of that same
relation. That's actually an error, not a warning. But they aren't
present in the simplified file of 1.osm (I haven't checked the other files).
I've seen that border ways aren't tagged. At least they should have the
following tags [1]:
boundary=administrative
admin_level="the highest (lowest number) level it shares"
Right, I missed that since a lot of the existing ones in my area only
have the tags on the relation not on the ways, and JOSM and osm-carto
display them as admin boundaries even without the tag on the ways.
We can add the boundary=administrative tag, but adding the admin_level
of the highest level it shares, I'm not sure how we can easily do
that. It makes it harder for us human editors to maintain the data and
it's more error prone as could become out of sync with the relations.
Adding source=* to those ways is also recommended.
Ok.
Between the admin_level=6 Willoughby City and Ryde City councils, along
the Lane Cove river, I see that the river basin is an admin_level_6
"council" called "Unincorporated". Is that correct? I ask this because I
see that the current OSM "Council of the city of Ryde" border
(admin_level=6 too) goes along the centre of the river.
Truth is I don't know. The existing NSW LGA boundaries are from a NSW
source which has each LGA meet in the river centerline, this country
wide PSMA source says the river isn't part of any LGA and put's the
two LGAs to the riverbank on each side.
NSW already has these admin boundaries as you can see, so we're not
planning on importing NSW, however these are still good questions.
I also see that the to-be-imported borders of Willoughby and Ryde city
councils don't adapt to the river banks as they are now in OSM. Will
things like these be manually conflated with existing OSM data? I don't
see that in the wiki yet. Maybe that could be extended from the point
"Apply any coastline conflation if using the existing coastline as some
of the boundaries (or this can be done post-import)" that you have
already in the Workflow section of the wiki, so river banks would be
included in that conflation together with coastline.
Again good question. This has been discussed on the local au mailing
list. Most voices there preferred not to re-use existing
waterway/road/etc as part of the admin boundary relation. The two main
reasons given were:
1. if the watercourse moves then the admin boundary doesn't so they
shouldn't be linked
2. people end up breaking admin boundaries when they change roads, rivers etc.
There was a discussion a few years back about Unincorporated LGA areas
I think this is something we still need to work out
https://en.wikipedia.org/wiki/Unincorporated_area#Australia However,
these water based areas marked unincorporated, shouldn't be imported.
I agree we should add that to the wiki.
Please, note that these were actually questions, not issues, as you
australians know better the local laws, etc.
Only one opinion: the fact that people break sometimes relations (in
this case boundaries that share the course of a river) shouldn't prevent
us of mapping the boundaries like that, if the law says that the river
is, by law, the border between two administrative entities. This is in
general; I am not saying that the local law says that the river is the
border or another thing, as I don't know it.
As for the changeset tags, I would add:
type=import
Although not important, you may consider to change the source to:
source=PSMA_Admin_Boundaries
and add:
source:date=August_2018
I've updated the changeset tags on the wiki, though I used the date
format 2018-08.
Great! 2018-08 is the correct one.
The changeset tag review_requested=yes (available as an option already
in JOSM (and iD)) may help you if you want to include validation in the
workflow.
Ideally this review here would be the review, it's going to be better
to pick up things before rather than after.
I agree.
This is all that I've seen. I hope it can help you.
Yes it's always helpful to have an extra pair of eyes.
You are welcome!
Cheers,
Rafael.
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports
