[talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

On Wed, 16 Sep 2020 at 20:07, Andrew Davidson <theswavu at gmail.com> wrote:

> On 15/9/20 10:53 pm, Andrew Harvey wrote:
> >
> > 1. psma:loc_pid. Where this is a stable ID that is used as a reference,
> > the existing ref tag is better for this. If we want to be more specific
> > then ref:psma or something like that would work. No need to invent new
> > tags here when one already exists, is well documented and in widespread
> use.
>
> I've never really considered these to be more than tagging for dataset
> maintainers, I didn't really think that any data consumers would want to
> use these. I would not put these under ref=* as they aren't really
> references that end users would see.
>

I guess it could be done either way, eg. wikidata IDs are done as their own
key http://wiki.openstreetmap.org/wiki/Key:wikidata. Same for iata and icao
https://wiki.openstreetmap.org/wiki/Key:icao.

However also some ref:namespace tags like
https://wiki.openstreetmap.org/wiki/Key:ref:isil and
https://wiki.openstreetmap.org/wiki/Key:ref:wigos and
https://wiki.openstreetmap.org/wiki/Key:ref:whc

Of course the big issue with non-namespaced ref is there can only be one,
and by the looks of it these are something PSMA ad and PSMA are certainly
not the authority on defining LGAs and Suburb/Localities. So for that
reason alone, I change my mind, it shouldn't be non-namespaced ref.

So while I'd prefer using ref:<namespace> I guess some psma specific tag
could be okay.

Though I'm not too fussed either way, if others have a different opinion
I'm happy to go with whatever.

> 2. Regarding source tags on objects, this might be something I added
> > originally, I can't remember, but I'm on the fence about it.
>
> The majority view at the time that we discussed this was to add a source
> tag. I understand that the source tag does have a decay function as to
> it's usefulness but it's still better than changeset tagging, which
> become useless the moment you upload the data. Maybe if Overpass could
> search for something based on the changeset tags of the last modifying
> changeset they would be useful, but till that tag I prefer to have them
> in-channel.
>
> If the general view is now that adding a source tag is not worthwhile
> then we can leave them out.
>




>
> > The "import" upload
> > should immediately be correct and not a broken state until post-import
> > changes clean things up, it should be uploaded clean in the first
> > instance.
>
> I agree with you 100%. The reason the current workflow has us deleting
> the outer ways before uploading is because this is what you wanted:
>
> https://lists.openstreetmap.org/pipermail/talk-au/2018-October/012131.html
>
> I'm happy to upload valid boundaries which is what I suggested:
>
> https://lists.openstreetmap.org/pipermail/talk-au/2018-October/012132.html


So you're suggesting 1) uploading duplicate state borders, and then cleanup
after import or 2) doing the upload so that it immediately uses the
existing state borders?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20200917/94b8f5c6/attachment.htm>