Re: [talk-au] PSMA Administrative Boundaries

[cleary]

I'll look there. Thanks.



On Sun, Oct 7, 2018, at 12:31 PM, Warin wrote:
> On 07/10/18 11:22, cleary wrote:
> >
> > In regard to admin boundaries sharing the coastline, I think that would 
> > also be incorrect but I am less confident of my view on this.
> >
> > I did update some administrative boundaries in South Australia using the SA 
> > Government Data and those boundaries did not coincide with the coastline 
> > (see the coastline around Streaky Bay, Ceduna, Fowlers Bay and near the 
> > Nullarbor).  The coastline in OSM needs a lot of work - I have looked at 
> > parts of WA and SA but found it very difficult to use the satellite imagery 
> > correctly to refine the map of the coastline in areas where there are 
> > extensive mudflats or large tidal flows and even rocky areas just 
> > under/above the waterline. But I suggest it is safest, and more accurate, 
> > to map the administrative boundaries and the coastline separately.
> 
> Might be good to look at Broome for hi/low tide .. there is a fair 
> distance between the two there so it would be easy to pick in that 
> location.
> 
> 
> ___
> 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

[Warin]

PS While on coast lines ... computer model of the Kimberly coastline 
over a few thousand years.. looks like it is breathing.


http://www.abc.net.au/news/2018-10-07/wa-coastline-transformed-by-sea-levels-over-thousands-of-years/10338500

On 07/10/18 11:22, cleary wrote:


In regard to admin boundaries sharing the coastline, I think that would also be 
incorrect but I am less confident of my view on this.

I did update some administrative boundaries in South Australia using the SA 
Government Data and those boundaries did not coincide with the coastline (see 
the coastline around Streaky Bay, Ceduna, Fowlers Bay and near the Nullarbor).  
The coastline in OSM needs a lot of work - I have looked at parts of WA and SA 
but found it very difficult to use the satellite imagery correctly to refine 
the map of the coastline in areas where there are extensive mudflats or large 
tidal flows and even rocky areas just under/above the waterline. But I suggest 
it is safest, and more accurate, to map the administrative boundaries and the 
coastline separately.






___
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

[Warin]

On 07/10/18 11:22, cleary wrote:


In regard to admin boundaries sharing the coastline, I think that would also be 
incorrect but I am less confident of my view on this.

I did update some administrative boundaries in South Australia using the SA 
Government Data and those boundaries did not coincide with the coastline (see 
the coastline around Streaky Bay, Ceduna, Fowlers Bay and near the Nullarbor).  
The coastline in OSM needs a lot of work - I have looked at parts of WA and SA 
but found it very difficult to use the satellite imagery correctly to refine 
the map of the coastline in areas where there are extensive mudflats or large 
tidal flows and even rocky areas just under/above the waterline. But I suggest 
it is safest, and more accurate, to map the administrative boundaries and the 
coastline separately.


Might be good to look at Broome for hi/low tide .. there is a fair distance 
between the two there so it would be easy to pick in that location.


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

Re: [talk-au] PSMA Administrative Boundaries

[cleary]

In regard to admin boundaries sharing the coastline, I think that would also be 
incorrect but I am less confident of my view on this.

I did update some administrative boundaries in South Australia using the SA 
Government Data and those boundaries did not coincide with the coastline (see 
the coastline around Streaky Bay, Ceduna, Fowlers Bay and near the Nullarbor).  
The coastline in OSM needs a lot of work - I have looked at parts of WA and SA 
but found it very difficult to use the satellite imagery correctly to refine 
the map of the coastline in areas where there are extensive mudflats or large 
tidal flows and even rocky areas just under/above the waterline. But I suggest 
it is safest, and more accurate, to map the administrative boundaries and the 
coastline separately.






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

Re: [talk-au] PSMA Administrative Boundaries

[Warin]

On 06/10/18 21:34, Andrew Harvey wrote:

Thanks for raising that. I'd seen some boundaries in WA defined in
legislation as, follow this road, then that road etc. but I think that
was for school zones. So the LGA and Suburb/Localities are defined by
the cadastral plans then?

I hear the points and see there is consensus to not reuse existing
roads, rivers in the admin boundaries, so I support that approach.

What about admin boundaries that border the coastline? Should they
share the existing coastline or not?


OSM has defined the 'coast line' as the high tide mark as that is easier to 
pick than the low or mid tide marks.
It is probable that the admin boundaries use the low tide mark?
Do a sample comparison?




That does simplify the import, as there is much less manual effort needed.

I guess what we need now is an OSM XML file with both the
Suburb/Localities and LGA boundaries together with shared ways (as
many ways are in common). I'll see what I can do to put this together,
is anyone else working on this too?

On Sat, 6 Oct 2018 at 20:53, cleary  wrote:

In regard to administrative boundaries being attached to other features such as 
waterways and roads, I think it is a trade-off between accuracy and convenience.

I am most familiar with NSW. Boundaries are not "defined" by words but rather by 
surveyors' charts. The surveyors may often have been directed to use waterways, roads, mountain 
ridges and similar features for their surveys. However the waterways and roads have sometimes/often 
moved but the boundaries have not.  Words are sometimes used to describe boundaries such as 
"it follows the river and then goes south along the main road ... " Such a description is 
approximate and is near enough for many purposes, especially if one's area of interest is well 
within the boundaries. However it may not be sufficiently precise if one is concerned with 
particular locations close to the boundaries.


Examples in NSW that might be considered include the boundary on the Murray 
River west of Tocumwal, the Lachlan River east of Cobb Highway, Willandra Creek 
south of Roto, Bogan River at Girilambone. If the boundaries were attached to 
the respective waterways, either the boundaries or the waterways would be 
incorrect. Where boundaries are mapped on rivers or roads, mappers may re-align 
the river or road as changes occur and the administraitve boundary becomes 
distorted, sometimes only slightly but usually increasingly significant over 
time. Alternatively we could map the waterway or road using the administrative 
boundary data (as some mappers have done in the past) and ignore the satellite 
imagery and GPS data but this affects the accuracy of the location of the 
waterway or road.

While I will accept the community's group decision, personally I think accuracy 
is to be valued over convenience.  I strongly advocate for accuracy by mapping 
administrative boundaries separate from other features on the map, even if they 
are nearby.

The decision in regard to the above issue will affect use of a source tag for 
the boundary. If the boundary is an approximation and attached to waterways or 
roads then it would be incorrect to use a boundary source tag, However if 
boundaries are mapped separately and accurately, then we should record the 
source of the boundary data. While I would suggest adding the source tag to the 
relation for the administrative boundary, it might also be added to the way if 
there is any need to specify the source for the way e.g. if using the 
administrative boundary for the geography of a river, then also give the source 
of the boundary data as the source for the waterway.

___
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: [OSM-talk-fr] hebdoOSM Nº 428 2018-09-25-2018-10-01

[deuzeffe]

On 10/6/18 3:11 PM, theweekly@gmail.com wrote:

Bonjour,

Le résumé hebdomadaire n° 428 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10770/


Est-ce que l'outil https://zlant.github.io/parking-lanes (que je 
découvre donc via weeklyosm) ne pourrait pas être intégré dans WhatOSM 
d'Adrien ?


--
deuzeffe, qui a encore trouvé un nouveau jeu dans OSM.

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

[Talk-de] 30er Zone (Z274.1)

[Martin Scholtes]

Moin zusammen,

wollte mal eben wieder eine Straße mit dem 30er Zone Zusatz ergänzen und
festgestellt, das im Wiki drei Varianten vonsource:maxspeed gibt.

Welche ist den nun eigentlich die offizielle?

https://wiki.openstreetmap.org/wiki/DE:Key:source:maxspeed


Gruß
Martin

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

Re: [OSM-talk-fr] Horaires d'ouverture

[Gwenaël Jouvin]

Je profite de ces messages pour indiquer ou rappeler l’existence de ce très 
pratique outil de vérification :
http://openingh.openstreetmap.de/evaluation_tool/?setLng=fr

et bien sûr, la page principale du wiki :
https://wiki.openstreetmap.org/wiki/FR:Key:opening_hours

Waxy, la réponse à ta question est dedans (je taquine en mode RTFM ;-) )


On 06/10/2018 16:34, Philippe Verdy wrote:
> Sa[1] = 1er samedi du mois
> 
> Le sam. 6 oct. 2018 à 16:18, Waxy  > a écrit :
> 
> Salut,
> 
> Comment on dit "tous les premiers samedis du mois" en opening_hours ? 樂
> 
> Pour https://www.facebook.com/Marche-Paysan-De-Coconi-1469553479997566/
> 
> @+
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

[Talk-it] itWikiCon 2018

[Dario Crespi]

Ciao a tutti,

vi scrivo per segnalarvi che sono aperte le iscrizioni alla seconda
edizione di itWikiCon, che quest'anno si terrà dal 16 al 18 novembre a
Como. Per iscrivervi (ed eventualmente chiedere una borsa di
partecipazione) andate qui: https://www.itwikicon.org/partecipa/

Il programma si trova qui:
https://meta.wikimedia.org/wiki/ItWikiCon/2018/Programma
Come vedete, ci sono ancora degli slot liberi: se qualcuno avesse parlare
di qualcosa relativo a OSM, può farsi avanti rispondendo a questa mail.

Tutte le informazioni logistiche si trovano sul sito dell'evento:
https://www.itwikicon.org/

Spero che qualcuno di voi possa venire :-)

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

Re: [Talk-cz] Oznaceni shop= pokud ma vice zamereni

[majka]

Podle mě máš tři možnosti:
- nacpat to všechno do jednoho a použít odddělovač. Spousta programů s tím
bude mít problém, ale teoreticky asi nejsprávnější.
- vrazit tam jen "hlavní" tag a na ostatní se vybodnout
- nacpat tagy na samostatné body.

Osobně bych patrně zvolila kombinaci posledních dvou bodů - tj. dát
samostatně čistírnu a samostatně second hand. Mapa (render) si to nějak
přebere, a při vyhledávání to ty body najde.

Majka

On Sat, 6 Oct 2018 at 18:02, mahdi1234  wrote:

> cau,
>
> jak byste oznacili nasledujici? http://imgbox.com/RzzSi4mN
>
> hodi se na nej shop=
>
> - dry_cleaning
> - laundry
> - second_hand
> - shoe_repair
>
> Nicmene josm mi dovoli jen jednu hodnotu pro tag shop. Muze je nak
> pouzit vsechny napr pomoci oddelovace?
>
> dik,
> mahdi
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] Oznaceni shop= pokud ma vice zamereni

[mahdi1234]

cau,

jak byste oznacili nasledujici? http://imgbox.com/RzzSi4mN

hodi se na nej shop=

- dry_cleaning
- laundry
- second_hand
- shoe_repair

Nicmene josm mi dovoli jen jednu hodnotu pro tag shop. Muze je nak
pouzit vsechny napr pomoci oddelovace?

dik,
mahdi

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

Re: [OSM-talk-fr] Horaires d'ouverture

[Philippe Verdy]

Sa[1] = 1er samedi du mois

Le sam. 6 oct. 2018 à 16:18, Waxy  a écrit :

> Salut,
>
> Comment on dit "tous les premiers samedis du mois" en opening_hours ? 樂
>
> Pour https://www.facebook.com/Marche-Paysan-De-Coconi-1469553479997566/
>
> @+
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Horaires d'ouverture

[Waxy]

Salut,

Comment on dit "tous les premiers samedis du mois" en opening_hours ? 樂

Pour https://www.facebook.com/Marche-Paysan-De-Coconi-1469553479997566/

@+

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

[Talk-ko] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

매주 일어나는 OSM 소식을 종합한, 428번째 주간OSM이 발행되었습니다.

http://www.weeklyosm.eu/ko/archives/10770/

읽어 주셔서 감사합니다!

주간OSM이란? 
누가?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
어디서?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

[OSM-talk-fr] hebdoOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 428 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10770/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-es] semanarioOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Hola, el semanario Nº 428, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10770/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-ca] hebdoOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 428 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10770/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-cu] semanarioOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Hola, el semanario Nº 428, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10770/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

[Talk-ht] hebdoOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 428 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10770/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[Talk-africa] hebdoOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 428 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10770/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[Talk-us] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-ca] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-GB] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-co] semanarioOSM Nº 428 2018-09-25-2018-10-01

[theweekly . osm]

Hola, el semanario Nº 428, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10770/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[OSM-talk-ie] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[OSM-talk] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-in] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[talk-ph] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-africa] weeklyOSM #428 2018-09-25-2018-10-01

[weeklyteam]

The weekly round-up of OSM news, issue # 428,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10770/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

Thanks for raising that. I'd seen some boundaries in WA defined in
legislation as, follow this road, then that road etc. but I think that
was for school zones. So the LGA and Suburb/Localities are defined by
the cadastral plans then?

I hear the points and see there is consensus to not reuse existing
roads, rivers in the admin boundaries, so I support that approach.

What about admin boundaries that border the coastline? Should they
share the existing coastline or not?

That does simplify the import, as there is much less manual effort needed.

I guess what we need now is an OSM XML file with both the
Suburb/Localities and LGA boundaries together with shared ways (as
many ways are in common). I'll see what I can do to put this together,
is anyone else working on this too?

On Sat, 6 Oct 2018 at 20:53, cleary  wrote:
> In regard to administrative boundaries being attached to other features such 
> as waterways and roads, I think it is a trade-off between accuracy and 
> convenience.
>
> I am most familiar with NSW. Boundaries are not "defined" by words but rather 
> by surveyors' charts. The surveyors may often have been directed to use 
> waterways, roads, mountain ridges and similar features for their surveys. 
> However the waterways and roads have sometimes/often moved but the boundaries 
> have not.  Words are sometimes used to describe boundaries such as "it 
> follows the river and then goes south along the main road ... " Such a 
> description is approximate and is near enough for many purposes, especially 
> if one's area of interest is well within the boundaries. However it may not 
> be sufficiently precise if one is concerned with particular locations close 
> to the boundaries.
>
>
> Examples in NSW that might be considered include the boundary on the Murray 
> River west of Tocumwal, the Lachlan River east of Cobb Highway, Willandra 
> Creek south of Roto, Bogan River at Girilambone. If the boundaries were 
> attached to the respective waterways, either the boundaries or the waterways 
> would be incorrect. Where boundaries are mapped on rivers or roads, mappers 
> may re-align the river or road as changes occur and the administraitve 
> boundary becomes distorted, sometimes only slightly but usually increasingly 
> significant over time. Alternatively we could map the waterway or road using 
> the administrative boundary data (as some mappers have done in the past) and 
> ignore the satellite imagery and GPS data but this affects the accuracy of 
> the location of the waterway or road.
>
> While I will accept the community's group decision, personally I think 
> accuracy is to be valued over convenience.  I strongly advocate for accuracy 
> by mapping administrative boundaries separate from other features on the map, 
> even if they are nearby.
>
> The decision in regard to the above issue will affect use of a source tag for 
> the boundary. If the boundary is an approximation and attached to waterways 
> or roads then it would be incorrect to use a boundary source tag, However if 
> boundaries are mapped separately and accurately, then we should record the 
> source of the boundary data. While I would suggest adding the source tag to 
> the relation for the administrative boundary, it might also be added to the 
> way if there is any need to specify the source for the way e.g. if using the 
> administrative boundary for the geography of a river, then also give the 
> source of the boundary data as the source for the waterway.

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

Re: [talk-au] PSMA Administrative Boundaries

[Warin]

On 06/10/18 20:52, cleary wrote:

In regard to administrative boundaries being attached to other features such as 
waterways and roads, I think it is a trade-off between accuracy and convenience.



+1.

If the admin boundaries use other features as there boundaries then it is the 
other feature that takes priority in accuracy over that of the boundary.

The tags on the way will have those of the other feature, possibly including 
the source of that other feature.

If the admin boundary is moved because the other feature is changed then so be 
it.
I have come across a few admin boundaries that are attached to things .. and 
from now on I'll move them to match the other feature, if that is a problem for 
you then make the admin boundary separate. I for one am tired of separating 
them.



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

Re: [talk-au] PSMA Administrative Boundaries

[cleary]

In regard to administrative boundaries being attached to other features such as 
waterways and roads, I think it is a trade-off between accuracy and 
convenience. 

I am most familiar with NSW. Boundaries are not "defined" by words but rather 
by surveyors' charts. The surveyors may often have been directed to use 
waterways, roads, mountain ridges and similar features for their surveys. 
However the waterways and roads have sometimes/often moved but the boundaries 
have not.  Words are sometimes used to describe boundaries such as "it follows 
the river and then goes south along the main road ... " Such a description is 
approximate and is near enough for many purposes, especially if one's area of 
interest is well within the boundaries. However it may not be sufficiently 
precise if one is concerned with particular locations close to the boundaries.

Examples in NSW that might be considered include the boundary on the Murray 
River west of Tocumwal, the Lachlan River east of Cobb Highway, Willandra Creek 
south of Roto, Bogan River at Girilambone. If the boundaries were attached to 
the respective waterways, either the boundaries or the waterways would be 
incorrect. Where boundaries are mapped on rivers or roads, mappers may re-align 
the river or road as changes occur and the administraitve boundary becomes 
distorted, sometimes only slightly but usually increasingly significant over 
time. Alternatively we could map the waterway or road using the administrative 
boundary data (as some mappers have done in the past) and ignore the satellite 
imagery and GPS data but this affects the accuracy of the location of the 
waterway or road.

While I will accept the community's group decision, personally I think accuracy 
is to be valued over convenience.  I strongly advocate for accuracy by mapping 
administrative boundaries separate from other features on the map, even if they 
are nearby.  

The decision in regard to the above issue will affect use of a source tag for 
the boundary. If the boundary is an approximation and attached to waterways or 
roads then it would be incorrect to use a boundary source tag, However if 
boundaries are mapped separately and accurately, then we should record the 
source of the boundary data. While I would suggest adding the source tag to the 
relation for the administrative boundary, it might also be added to the way if 
there is any need to specify the source for the way e.g. if using the 
administrative boundary for the geography of a river, then also give the source 
of the boundary data as the source for the waterway.





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

[Talk-us] Open Data track at SCaLE 17x

[Wolfgang Zenker]

Hi,

I just noticed that the Southern California Linux Expo 2019 in Pasadena
will have an "Open Data" track. That looks like a good opportunity to
raise awareness about OpenStreetMap, so if someone would like to do a
presentation, the CfP is at https://www.socallinuxexpo.org/scale/17x/cfp

Greetings from Germany,
Wolfgang
( lyx @ osm )

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

Re: [Talk-cz] přidání tagu zruseno k fotce na Fody

[Tom Ka]

tag zruseno uz nema smysl, misto toho fotku disabluj a pripadne info o
tom, ze byla zrusena muzes dat do komentare.

bye
pá 5. 10. 2018 v 10:21 odesílatel Zdeněk Pražák  napsal:
>
> chtěl jsem k fotografii na Fody s ID 12461 přidat tag zruseno (Tento 
> rozcestník byl přesunut k rohu budovy nádraží viz foto s ID 20903)
> Když však tag odkliknu, objeví se hláška přidání tagu zruseno selhalo
>
> Pražák
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [OSM-talk-fr] Piscines avec bassin extérieur chauffé

[Philippe Verdy]

Je ne vois pas trop l'intérêt de "temperature=*", c'est forcément très
variable même si c'est chauffé (en certaines saisons).
Ce qui conduirait à une variante "heated=seasonal" (je ne suis pas sûr que
opening_hours s'applique pour ce cas, car il indiquerait plutôt la
fermeture saisonnière, mais il n'est pas non plus dit que quand c'est
ouvert ce soit chauffé pour autant; ceci dit "heated=yes" ne doit être que
rarement toute l'année, quelque soit le type de lieu, car on pourrait aussi
parler de la climatisation pour raffraichir un lieu et pas que l'eau de la
piscine et pas seulement en intérieur si on parle aussi des terrasses de
cafés-restaurants avec brumisateurs).
On peut aussi parler des piscines sous abri fermé qui s'ouvre en partie sur
l'extérieur en belle saison (toit mobile d'un bâtiment souvent alors en
forme de dôme), et non simplement de simples baies d'ouverture.
Enfin il y a des bassins intérieurs qui sont prolongés en un seul tenant à
l'extérieur avec une baie mobile de séparation (quand elle est fermée, la
partie extérieure est aussi couverte par un plancher mobile ou une
couverture flottante, mais la partie intérieure reste ouverte).

Autre considération : les piscines à l'eau de mer, n'utilisant pas (ou
seulement partiellement) l'eau douce de la collectivité. Cette eau est
souvent pompée et traitée et ces piscines sont souvent des lieux de cures
marines. L'eau de mer peut aussi être chauffée. Il y a aussi les
bassins-piscines d'eau de mer dont l'eau se renouvelle avec la marée qui
vient les recouvrir, la piscine retenant seulement l'eau à marée basse
(exemple sur une plage à Saint-Malo) : la "piscine" est essentiellement une
digue extérieure en béton accessible aux piétons et baigneurs à marée basse
avec des équipements (type plongeoir) et .

Le sam. 6 oct. 2018 à 10:24, marc marc  a écrit :

> Le 06. 10. 18 à 09:43, Paul Desgranges a écrit :
> > ouvert jusqu'au 22 déc.
>
> opening_hours :)
>
> >   heated=yes
> > Le 'heated' est non documenté et peu utilisé, c'est ce que j'ai trouvé
> > de mieux !
>
> il y a le tag temperature, si connue.
> certains semble même s'en servir pour des valeurs subjective.
> https://taginfo.openstreetmap.org/keys/temperature
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscines avec bassin extérieur chauffé

[marc marc]

Le 06. 10. 18 à 09:43, Paul Desgranges a écrit :
> ouvert jusqu'au 22 déc. 

opening_hours :)

> Au-delà des considérations écologiques

quel source d'énergie par curiosité ?

>       length=50

si tu l'as tagé comme un noeud, c'est utile.
sinon cela se déduit de sa géométrie.
Tu peux d'ailleurs ajuster as géométrie avec josm pour faire 50m
tout rond.

>       heated=yes
> Le 'heated' est non documenté et peu utilisé, c'est ce que j'ai trouvé 
> de mieux !

il y a le tag temperatue, si connue.
certains semble même s'en servir pour des valeurs subjective.
https://taginfo.openstreetmap.org/keys/temperature

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] PSMA Administrative Boundaries

[Joel H.]

>Do you have examples of the overlapping ways? It looks pretty okay
around Brisbane to me. Here's an a mesh of the LGA's in GeoJSON which
you can import into JOSM with enough memory.
https://tianjara.net/data/LGA_mesh.geojson.xz

Just import the shapefile into JOSM and use the validation. The GeoJSON
file is looking much cleaner.


>That's fairly easy to as a preprocessing step, eg with ogr2osm or via
other scripts. I've been working on processing the PSMA data to make it
easier to import. Since I think we should reuse existing ways where
possible, if we did that it's a mostly manual process anyway. Even
without reusing existing way, to get relations you need shared ways on
the borders. One approach is to use
https://github.com/andrewharvey/geojson-mesh to get single ways for the
border which we then manually join up into the full relations in JOSM.

We might just have to do this. It would be a lot faster then trying to
find overlapping ways, at least on the LGA data.


>If there's an existing place node, then we should use that as the label
member of the relation

Yes this is what I was intending.



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

[Talk-de] Wiki-Eintrag falsch?

[sepp1974]

...und außerdem macht es recht wenig Sinn, mich beim mappen erst durch 
ellenlange Forenthreads zu wühlen. Bei Unklarheiten schaue ich als 
allererstes ins Wiki <= Auslöser für diese Diskussion mit Zielstellung 
das Wiki anzupassen / zu aktualisieren.


Grüße Sepp


mmd mmd.osm at gmail.com
Sa Okt 6 06:36:51 UTC 2018

Vorherige Nachricht: [Talk-de] Wiki-Eintrag falsch?
Nächste Nachricht: [Talk-de] Wiki-Eintrag falsch?
Nachrichten sortiert nach: [ Datum ] [ Thema ] [ Betreff (Subject) ] 
[ Autor ]


Moin

Am 06.10.2018 um 07:45 schrieb sepp1974 at posteo.de:


Aufgrund einer Vielzahl von alten Brückenbögen sind an diesen oft
mehrere Angaben zur Höhe zu finden, auch durch Z 265. So stehen an den
Bogenrändern im Lot über dem Fahrbahnrand oft deutlich geringere
Angaben, als in der Fahrbahnmitte. Vllt. sollte der Wert maxheight:
mehrfach für ein Objekt erfassbar sein, maxheight:*, maxheight_1:* oder
besser noch maxheigth_left:/_right:/_center: in Abhängigkeit zum
gezeichneten Straßenrichtungsverlauf? Damit ließen sich auch Brücken
schräg zum darunter liegenden Fahrbahnniveau eindeutig mit Höhenangaben
versehen, das wäre gerade für die gebirgigen Regionen sicher hoch
interessant, auch auf internationaler Ebene? So wären auch alte
Tunnelröhren sehr gut für den Verkehr darstellbar.



Das Thema maxheight wurde übrigens vor Jahren bereits ausgiebigst im
Forum diskutiert. Es gibt sogar eine Karte, die sich mit dem Thema
beschäftigt (räusper). Vielleicht schaust du auch mal in die alte
Diskussion rein:

https://forum.openstreetmap.org/viewtopic.php?pid=300099#p300099


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

[Talk-de] Wiki-Eintrag falsch?

[sepp1974]

Hab ich gelesen, das ändert nix an der Tatsache, das der Wiki-Eintrag 
falsch ist.


Wie soll man's richtig machen, wenn's nicht dokumentiert ist - räusper 
;-)


Gruß Sepp

PS: Wieso kriege ich die Mails nicht um darauf direkt zu antworten? Das 
ist immer nur copy & paste aus dem Archiv - deswegen haut auch die 
Baumstruktur nicht hin.




mmd mmd.osm at gmail.com
Sa Okt 6 06:36:51 UTC 2018

Vorherige Nachricht: [Talk-de] Wiki-Eintrag falsch?
Nächste Nachricht: [Talk-de] Intergeo 2018 in Frankfurt 
16.–18.10.2018
Nachrichten sortiert nach: [ Datum ] [ Thema ] [ Betreff (Subject) ] 
[ Autor ]


Moin

Am 06.10.2018 um 07:45 schrieb sepp1974 at posteo.de:


Aufgrund einer Vielzahl von alten Brückenbögen sind an diesen oft
mehrere Angaben zur Höhe zu finden, auch durch Z 265. So stehen an den
Bogenrändern im Lot über dem Fahrbahnrand oft deutlich geringere
Angaben, als in der Fahrbahnmitte. Vllt. sollte der Wert maxheight:
mehrfach für ein Objekt erfassbar sein, maxheight:*, maxheight_1:* oder
besser noch maxheigth_left:/_right:/_center: in Abhängigkeit zum
gezeichneten Straßenrichtungsverlauf? Damit ließen sich auch Brücken
schräg zum darunter liegenden Fahrbahnniveau eindeutig mit Höhenangaben
versehen, das wäre gerade für die gebirgigen Regionen sicher hoch
interessant, auch auf internationaler Ebene? So wären auch alte
Tunnelröhren sehr gut für den Verkehr darstellbar.



Das Thema maxheight wurde übrigens vor Jahren bereits ausgiebigst im
Forum diskutiert. Es gibt sogar eine Karte, die sich mit dem Thema
beschäftigt (räusper). Vielleicht schaust du auch mal in die alte
Diskussion rein:

https://forum.openstreetmap.org/viewtopic.php?pid=300099#p300099

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

[OSM-talk-fr] Piscines avec bassin extérieur chauffé

[Paul Desgranges]

Bonjour
 La piscine d'Echirolles 38130 a un bassin extérieur chauffé de 50m, 
ouvert jusqu'au 22 déc. Au-delà des considérations écologiques de 
déperdition d'énergie, etc. c'est assez génial de pouvoir en profiter 
... Et je m'interroge sur d'autres bassins de mêmes caractéristiques en 
France ? Savez-vous s'il y en a d'autres ?


J'ai taggé ce bassin comme ceci:
     leisure=swimming_pool
     location=outdoor
     length=50
     heated=yes
Le 'heated' est non documenté et peu utilisé, c'est ce que j'ai trouvé 
de mieux !


    Bassins extérieurs : https://overpass-turbo.eu/s/Cyt
    Chauffés : https://overpass-turbo.eu/s/Cyx

Merci et bonne journée
Paul


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

Re: [Talk-de] Wiki-Eintrag falsch?

[mmd]

Moin

Am 06.10.2018 um 07:45 schrieb sepp1...@posteo.de:

> Aufgrund einer Vielzahl von alten Brückenbögen sind an diesen oft
> mehrere Angaben zur Höhe zu finden, auch durch Z 265. So stehen an den
> Bogenrändern im Lot über dem Fahrbahnrand oft deutlich geringere
> Angaben, als in der Fahrbahnmitte. Vllt. sollte der Wert maxheight:
> mehrfach für ein Objekt erfassbar sein, maxheight:*, maxheight_1:* oder
> besser noch maxheigth_left:/_right:/_center: in Abhängigkeit zum
> gezeichneten Straßenrichtungsverlauf? Damit ließen sich auch Brücken
> schräg zum darunter liegenden Fahrbahnniveau eindeutig mit Höhenangaben
> versehen, das wäre gerade für die gebirgigen Regionen sicher hoch
> interessant, auch auf internationaler Ebene? So wären auch alte
> Tunnelröhren sehr gut für den Verkehr darstellbar.
> 

Das Thema maxheight wurde übrigens vor Jahren bereits ausgiebigst im
Forum diskutiert. Es gibt sogar eine Karte, die sich mit dem Thema
beschäftigt (räusper). Vielleicht schaust du auch mal in die alte
Diskussion rein:

https://forum.openstreetmap.org/viewtopic.php?pid=300099#p300099

-- 




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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

On Sat, 6 Oct 2018 at 15:57, Joel H.  wrote:
>
> OK everyone I am currently editing the LGA shapefiles for QLD so no one 
> should attempt as to not create conflicts (although I'm not currently working 
> on the suburbs file).

Don't worry, no one should actually be doing any importing until we
get community consensus and a plan in place.

> The PSMA data isn't good IMO. And requires a lot of fixing to be imported, 
> lots of problems with overlapping ways.

Do you have examples of the overlapping ways? It looks pretty okay
around Brisbane to me. Here's an a mesh of the LGA's in GeoJSON which
you can import into JOSM with enough memory.
https://tianjara.net/data/LGA_mesh.geojson.xz

> But the biggest problem is that the names are all caps! Does anyone know a 
> way to automatically convert all of these properly so that "BRISBANE" is 
> "Brisbane"?

That's fairly easy to as a preprocessing step, eg with ogr2osm or via
other scripts.

I've been working on processing the PSMA data to make it easier to
import. Since I think we should reuse existing ways where possible, if
we did that it's a mostly manual process anyway. Even without reusing
existing way, to get relations you need shared ways on the borders.

One approach is to use https://github.com/andrewharvey/geojson-mesh to
get single ways for the border which we then manually join up into the
full relations in JOSM.

> On 6/10/18 12:07 pm, Joel H. wrote:
> My first though is to add a fixme notice (in similar fashion to the NSW 
> import), that tells us to reconsider the place label node already in OSM, and 
> to integrate it with the boundary data.

If there's an existing place node, then we should use that as the
label member of the relation.

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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

On Fri, 5 Oct 2018 at 11:43, cleary  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