[talk-au] PSMA Administrative Boundaries

Andrew Harvey andrew.harvey4 at gmail.com
Sat Oct 6 06:09:20 UTC 2018


On Fri, 5 Oct 2018 at 11:43, cleary <osm at 97k.com> wrote:
> A month ago, we celebrated the news that OSM now has approval to use the PSMA Administrative Boundaries and there was some discussion, including the need for a proper import process.  I am willing to start adding some boundaries in areas with which I am familiar/interested but I am waiting for the proper import process to be determined. I am not aware if anything has been done in regard to a plan to import this data. If so, please guide me.

Glad to see people are interested in bringing this data into OSM. I'm
strongly of the view that we should discuss and document the import
process before beginning, so naturally that's the first step.

>If not, I propose the following:
> Individual mappers download most recent data from https://data.gov.au/dataset/psma-administrative-boundaries and add/check data in their areas of interest and/or when they have time.  (Andrew Harvey has provided a script to assist working with PSMA Administrative Boundaries Data and there is a link on https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue)
>
> Administrative boundaries in NSW, SA, VIC and ACT be modified instance-by-instance if there are discrepancies that require updating. Where there are discrepancies, the most recent data is usually preferred . If there are concerns about accuracy of the most recent data, further consultation with other mappers or relevant government boundary authorities would be appropriate.
>
> In QLD, WA, TAS and NT :  LGA and Suburb/Locality boundaries be added one at a time, integrating with existing data where appropriate.  Previous data from unauthorised sources be deleted or the authorised source be added if the data is accurate.
>
> LGA Boundaries continue to be tagged as admin_level=6
> Suburb/Locality boundaries be tagged as admin_level=10

I agree.

> In both instances source=PSMA_Admin_Boundaries_August_2018
> (or whichever date is applicable to the most recent data being used)
> This source information may seem unwieldy but provides accuracy and completeness of information.

I'm on the fence on this, while the source tag on the feature can be
very handy for mappers, I've also seen the downside where as other
tags are added later on it becomes unclear what actually came from
that source. Where do you propose this tag to go, on the relation or
on the way members of the relation?

Consistent with existing LGA boundaries in OSM I'm proposing we use
relations with the tags:

type=boundary
boundary=administrative
admin_level=6
place=municipality

with optional tags

short_name=Sydney
name=City of Sydney
wikidata=
wikipedia= (optional with wikidata tag)
website=
phone=
email=

the admin boundary ways as "outer" members.

Consistent with existing Suburb/Locality boundaries in OSM I'm
proposing we use relations with the tags:

type=boundary
boundary=administrative
admin_level=10
place=suburb
name=

with optional tags:

postal_code (although there's not 1:1 match between postal areas and
suburbs, I'm okay with adding a postal code that generally applies to
the suburb so long as it's not coming from copyrighted sources)
wikidata
wikipedia (optional with wikidata tag)

> Administrative boundaries NOT be attached to other ways such as creeks, rivers, roads, etcetera so that the other features can be modified as needed without affecting the administrative boundaries which are generally static.

I disagree with that. If the admin boundary seems to follow the creek,
river, road, coastline then we should use that existing way as part of
the relation.

I'd like to avoid a "mess" of multiple ways all very close to each
other and overlapping.

Plus if the boundary is defined as that river, road, coastline then by
using the existing way we are able to capture that detail in OSM in a
way that almost all other spatial data cannot.

> Multiple administrative boundaries (including national_parks and government approved protected_areas or state forests) be mapped on a single way, where appropriate, and with multiple relations attached to that single way i.e. a single way could form the boundaries for localities, LGAs and a national park, if appropriate in the particular location.

I agree.

> Electoral boundaries NOT be added at this time.

I agree.

> Other boundaries which have been discussed, such as regions and indigenous areas, NOT be added as part of this particular project unless they are LGAs or Suburbs/Localities (some indigenous areas may be identified as protected areas or defined localities or LGAs, in which case they are added and identified on that basis). Mapping of regions could be further discussed separately if required. They are usually not defined by legislation and therefore usually not "administrative" in the way that LGAs and Suburbs/Localities are legislated.

I agree, plus these other types of regions aren't covered by the PSMA
Admin Boundaries dataset anyway, so let's leave that as a separate
discussion.



More information about the Talk-au mailing list