[Imports] Australian administrative boundaries import

Rafael Avila Coya ravilacoya at gmail.com
Tue Oct 23 17:04:17 UTC 2018


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 <ravilacoya at gmail.com> 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
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
> 



More information about the Imports mailing list