[talk-au] Namespace for maintenance tags

[Andrew Davidson]

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 have been pondering this further and I'm wondering if these type of 
maintenance tags would be more appropriate in the note namespace. So:


note:*=*

rather than

ref:*=*

as note=* is for information for other mappers.

Any thoughts/objections/counter proposals?

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Admin_level discussion for Australia

[Ewen Hill]

Thank you Andrew H for your un-waivering (sic) efforts and changing the
entire way the Australian map is developing. Chapeau!

Andrew's last message in part, discussed how the admin_levels are defined
as and prompted for some suggestions, namely level 9 and 10 and if we
should include electoral boundaries.

I have set up a quick spreadsheet outlining the admin_levels and I think I
have transcribed Andrew's thoughts on how it may work and added mine.

Feel free to add your preferred layout in the next available col and add a
comment if you wish.

https://docs.google.com/spreadsheets/d/1dzOJoOL6sVLinzqZDcC2wOj-e_2BNz5QFkI-xGnpJXI/edit?usp=sharing

-- 
Ewen
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Davidson]

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.


The two options would be:
1. the ref: namespace or
2. ref:AU: namespace which is similar to what the FR community seems to use:

https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Any opinions?

If this is how people would like to tag these types of ids I would also 
have to go back and modify all of the others I have created over the years.


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

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au