Re: [talk-au] PSMA Administrative Boundaries

2020-09-15 Thread Andrew Harvey
On Wed, 16 Sep 2020 at 10:44, cleary  wrote:

> Thanks to both Andrew Davidson and Andrew Harvey for their work as I see
> addition of PSMA administrative boundaries as an important improvement for
> our map.
>
> In regard to adding source tags to objects, I find them very helpful when
> editing something. If I think I have contrary information, I refer to the
> source of the existing data. If it is an authoritative source, I am
> prompted to go back and check my own information. Where information is
> unsourced or refers to a less authoritative source, then I am more likely
> to proceed with the edit or attempt to contact the mapper who entered the
> previous information.  Also I hope that by adding authoritative sources for
> my edits, other mappers will be less likely to make changes without
> contacting me or at least double-checking the accuracy of their later
> information.  If information comes from multiple sources, then it may be
> appropriate to have multiple source tags e.g. source:geometry, source:name,
> source:alt_name etc.


I listened to a talk by Maurits van der Vlugt about "authoritative data"
once (slides
https://www.slideshare.net/MauritsV/authoritative-data-must-come-from-an-official-source
).

I think we give too much credit for so-called "authoritative data". Just
because the government publishes a GIS file of LGA and suburb boundaries,
doesn't mean it's 100% accurate because it's not, and so we shouldn't treat
these objects in OSM as immutable (I know you're not claiming that).

In regard to relations, it is possible to have different sources for the
> relation and for component ways,


Yes this is exactly how the import candidates have been prepared, I'm in
support of the source:geometry=* on the way, it's just the source=* on the
relation, especially where there will be many other tags added later that
I'm not so sure about.

Ways often get split, and so checking the history to find the source can be
difficult, but this isn't much of a problem for the relations.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [talk-au] PSMA Administrative Boundaries

2020-09-15 Thread cleary
Thanks to both Andrew Davidson and Andrew Harvey for their work as I see 
addition of PSMA administrative boundaries as an important improvement for our 
map.

In regard to adding source tags to objects, I find them very helpful when 
editing something. If I think I have contrary information, I refer to the 
source of the existing data. If it is an authoritative source, I am prompted to 
go back and check my own information. Where information is unsourced or refers 
to a less authoritative source, then I am more likely to proceed with the edit 
or attempt to contact the mapper who entered the previous information.  Also I 
hope that by adding authoritative sources for my edits, other mappers will be 
less likely to make changes without contacting me or at least double-checking 
the accuracy of their later information.  If information comes from multiple 
sources, then it may be appropriate to have multiple source tags e.g. 
source:geometry, source:name, source:alt_name etc.

In regard to relations, it is possible to have different sources for the 
relation and for component ways, e.g a relation for a waterway may show the 
source of information including the name sourced from a permitted government 
dataset but component segments of the waterway may be sourced from two 
different satellite imagery sources.  Again, I find sources helpful. Even state 
boundaries need verifying. At one time (not sure if it still the case) some SA 
Govt data showed some SA localities and protected areas as extending into NSW 
along parts of the shared border. After looking closely, I moved the OSM 
boundary slightly in some areas (generally preferring the NSW LPI data) but I 
was always careful to show the source of my data so that other mappers could 
verity or challenge me if appropriate.  Some administrative boundaries in OSM 
were sourced from ABS data which were always just approximations. ABS data was 
useful in OSM when we had nothing else, but not now that we have accurate data 
from official sources.  I have found it helpful to know the sources of the data 
I am looking at. 




On Tue, 15 Sep 2020, at 12:53 PM, Andrew Harvey wrote:
> Resurecting this old thread as Andrew Davidson has been working on this 
> import plan a bit more -> 
> https://wiki.openstreetmap.org/w/index.php?title=Import%2FCatalogue%2FPSMA_Admin_Boundaries&type=revision&diff=2034132&oldid=1918537
> 
> Surfacing a few points from my review:
> 
> 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.
> 
> 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. While on 
> one hand I can see it being helpful for mappers to understand where 
> these were sourced from, over time as people make changes in OSM the 
> source tag becomes inaccurate. I've seen this with existing source 
> tags, where people generally don't remove them if updating based on a 
> different source. Since you can always inspect the history to find the 
> source, is there really any benefit to having these on each object? 
> Given a whole bunch of other tags like contract details, website etc. 
> for LGAs can be added to, a top level source tag is not perfect. I'm 
> good with source:geometery on the ways, but not sure about source on 
> the relations.
> 
> 3. More of a question for Andrew Davidson, is the plan for the actual 
> upload to go through the state borders and other ways already existing 
> in OSM, and delete the one with FIXME from your candidates, and use the 
> existing state border as part of the new relation? 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. So this means manually working on it in JOSM before uploading.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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


Re: [talk-au] PSMA Administrative Boundaries

2020-09-15 Thread Andrew Harvey
Resurecting this old thread as Andrew Davidson has been working on this
import plan a bit more ->
https://wiki.openstreetmap.org/w/index.php?title=Import%2FCatalogue%2FPSMA_Admin_Boundaries&type=revision&diff=2034132&oldid=1918537

Surfacing a few points from my review:

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.

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. While on one
hand I can see it being helpful for mappers to understand where these were
sourced from, over time as people make changes in OSM the source tag
becomes inaccurate. I've seen this with existing source tags, where people
generally don't remove them if updating based on a different source. Since
you can always inspect the history to find the source, is there really any
benefit to having these on each object? Given a whole bunch of other tags
like contract details, website etc. for LGAs can be added to, a top level
source tag is not perfect. I'm good with source:geometery on the ways, but
not sure about source on the relations.

3. More of a question for Andrew Davidson, is the plan for the actual
upload to go through the state borders and other ways already existing in
OSM, and delete the one with FIXME from your candidates, and use the
existing state border as part of the new relation? 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.
So this means manually working on it in JOSM before uploading.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [talk-au] Admin levels for LGAs / suburbs etc changed (Was "Suburbs & admin boundaries stopping streets being found?)

2020-09-15 Thread Graeme Fitzpatrick
Thanks!

Graeme


On Sun, 13 Sep 2020 at 16:52, Andrew Davidson  wrote:

> Looks OK to me.
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au