Re: [talk-au] NSW LPI Data

[Andrew Harvey]

For OpenAddresses.io we used the NSW_Property endpoint which is listed as
CC BY
https://github.com/openaddresses/openaddresses/tree/master/sources/au/nsw.
Couldn't you have used that either directly or via OpenAddresses?

Other endpoints are not listed as CC BY so shouldn't be assumed to be, of
course we can ask to confirm.

They've now switched to CC BY 4.0 which means ideally they would complete
the new waiver form instead of the current permission email, but I just
haven't gotten around it asking yet. Plus I'm worried they might
change their mind if I bring up the topic again, though that's not a good
reason to not ask for the LWG's waiver.

On Sat, 25 Jul 2020 at 21:42, David Wales  wrote:

> Hmm...
> We might have a problem then, because we've been using the following
> endpoint to generate our address points:
>
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/3/query
>
> I was hoping to move to using the following instead, as it provides better
> locations for the addresses in some cases:
>
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>
> However, if we don't actually have permission for these endpoints, we're
> going to either need to get permission somehow, or revert and restart with
> the correct endpoint! :(
>
> Some guidance would be good here!
>
> Regards,
> David Wales
>
> On 25/7/20 5:45 pm, Andrew Harvey wrote:
>
> It should still apply, but as always only the services listed at
> https://www.spatial.nsw.gov.au/products_and_services/web_services/access_web_services
>  are
> covered, the Property Address endpoint is not directly listed and therefore
> cannot be assumed to be openly licensed.
>
> On Sat, 25 Jul 2020 at 17:35, David Wales  wrote:
>
>> Dear all,
>>
>> As part of the NSW Address Import
>> ,
>> we have been relying (I think) upon the following explicit permission:
>>
>>
>> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data
>>
>> However, the links mentioned in the permission no longer exist, as the
>> LPI services have migrated to SIX maps.
>> I'm just wanting to double-check that the permission still applies at the
>> new location, and if so, does it apply to all the arcgis endpoints
>> available in SIX maps? For example, the following:
>>
>> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>>
>> Regards,
>> David Wales
>> ___
>> 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-at] landuse: line oder multipolygon?

[Friedrich Volkmann]

On 25.07.20 15:05, Patrick Strasser-Mikhail wrote:

Eine Frage zu Stil und Praktikabilität:

Wenn ein detailliert gemaptes Gebiet ohne Lücken mit landuse oder 
gleichwertig getagt ist, dann stoßen ja immer exakt Flächen aneinander, 
entweder als geschlossene Linien oder als Multipolygone.


Es kommt aber immer wieder einmal vor, dass Ungenauigkeiten auftauchen, wie 
dass die aneinander stoßenden Linien nicht immer die gleichen Punkte 
verwenden, und dann bei Änderungen kleine Keile entstehen, wo dann halt nix 
ist, oder Überlappungen. Auch ein Klassiker ist, dass highway oder ähnliches 
sich Punkte mit der Linie teilt und dann das eine verschoben wird, aber 
ungewollt das andere mit verändert wird.


Mit Multipolygonen hätte man den Vorteil, dass idealerweise immer nur eine 
Linie eine Grenze darstellt, die von mehreren Multipolygon-Relationen 
verwendet wird. Nachteilig sehe ich aber, dass der Aufwand für Multipolygone 
deutlich höher ist, immer noch Fehler passieren können (irrtümliche einen 
highway als Multipolygon-Grenze gewählt), oder nicht-zusammgehörige Dingen 
mit einer gemeinsamen Linie "verbunden" werden.


Wie du schon festgestellt hast, können so oder so Fehler passieren.

Grundsätzlich sollten im Sinne einer Fehlerminimierung:
- Anfänger nicht an komplexen Gebilden herumpfuschen
- Leute nicht auf lustig Multipolygone anderer Mapper verändern, nur weil 
irgendein Validator eine Warnung ausgibt
- Jene Mapper entscheiden, die in einem Gebiet am meisten mappen - denn sie 
sind es, die mit der gewählten Variante zurechtkommen müssen.


Bitte keinesfalls Daten eines anderen verändern nur mit der Begründung, es 
für einen fiktiven Dritten einfacher zu machen. So à la "ich verstopfe jetzt 
den Rauchfang meines Nachbarn, damit kein Kind hineinfällt".


Gibt es dazu - abgesehen von den technischen Ausführungen im Wiki (die sich 
darauf beziehen, dass ein Multipolygon halt notwendig ist, wenn es Löcher 
gibt und die Rolle "inner" benötigt wird) - bekannte Kriterien, wann eine 
geschlossene Linie und wann ein Multipolygon sinnvoll sind?


Genau genommen ist ein Multipolygon nie nötig, denn man könnte die äußere 
Fläche als 2 Teilflächen mappen oder als sich selbst berührende Fläche 
(Wurm, der seinen Schwanz küsst). Aber abgesehen von technischen Problemen 
(z.B. früher renderte Mapnik dort, wo die Flächen zusammenstoßen, eine weiße 
Linie) sind solche Lösungen für andere Mapper irritierend. Eine Regel, die 
vielleicht nicht im Wiki steht, aber sich aus dem gesunden Menschenverstand 
ergibt: Jedes reale Objekt sollte als 1 Objekt in OSM abgebildet werden, und 
die Abbildung sollte dem Wesen nach der Realität entsprechen.


Da sehen wir auch gleich ein Problem beim Verwenden von Straßen als 
MP-outer: Sagen wir, die Straße begrenzt den Wald, dann tritt der Waldrand 
etwas zurück, dann tritt er wieder an die Straße heran, usw. Man muss dann 
die Straße mehrmals zerstückeln. Dann hat man mehrere Ways, obwohl es in der 
Realität nur eine einzige Straße ist. Das gleiche Problem haben wir 
natürlich auch, wenn wir maxspeed etc. auf einzelne Straßenabschnitte setzen 
wollen. Da geht es nicht anders, aber i.a. ist es wünschenswert, das 
Zerstückeln zu vermeiden. Eine praktische Auswirkung dieses Zerstückelns 
ist, dass Suchfunktionen wie Nominatim dann die Foobar-Straße nicht 1x 
finden und die ganze Straße anzeigen, sondern eine Liste von 20 
Straßenstückerln anzeigen. Theoretisch ließe sich das fixen, indem man den 
Straßennamen und -typ nicht auf die einzelnen Ways, sondern auf eine 
Multilinestring-Relation setzt, aber die meisten Anwendungen werten diese 
Relationen nicht aus, und damit verschwindet die Straße ganz von der Karte.


Eine Straße (oder einen Fluss, Zaun, etc.) als MP-outer zu nehmen, bringt 
vor allem dann was, wenn es ein langer Abschnitt ist, auf dem sehr viele 
Nodes liegen. Dann wäre es umständlich, die Straße für die Landusegrenze 
nachzuzeichnen.


Ähnliches gilt für MP vs. einfache Flächen: Wenn ein Landuse von den 
angrenzenden Landuses durch lange Linien mit vielen Nodes abgegrenzt ist, 
ist es zweckmäßig, die Flächen in Multipolygone umzuwandeln um die Linien 
nicht doppelt zeichnen zu müssen und dabei womöglich ein paar Nodes zu 
übersehen. Wenn es aber sehr viele, kurze Landuse-Grenzen mit wenig Nodes 
gibt, ist die Aufwandsersparnis gering. Ein MP mit vielen kurzen outer wird 
eher unübersichtlich und fehleranfällig.


Und gibt es praktikable Werkzeuge, die es erleichtern, vom einen in das 
andere System zu kommen, oder auch problematische Flächen zu reparieren?


Nein. Wenn du weißt, was du tust, brauchst du solche Tools nicht. 
Andernfalls lässt du sowieso besser die Finger davon.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [talk-au] NSW LPI Data

[Dion Moult]

Would it be possible to ask for permission for all of the endpoints?

On Sat, Jul 25, 2020 at 09:42:45PM +1000, David Wales wrote:
>Hmm...
>We might have a problem then, because we've been using the following
>endpoint to generate our address points:
>[1]https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAdd
>ress/MapServer/3/query
>I was hoping to move to using the following instead, as it provides
>better locations for the addresses in some cases:
>[2]https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAdd
>ress/MapServer/2
>However, if we don't actually have permission for these endpoints,
>we're going to either need to get permission somehow, or revert and
>restart with the correct endpoint! :(
>Some guidance would be good here!
>Regards,
>David Wales
> 
>On 25/7/20 5:45 pm, Andrew Harvey wrote:
> 
>It should still apply, but as always only the services listed
>at [3]https://www.spatial.nsw.gov.au/products_and_services/web_services
>/access_web_services are covered, the Property Address endpoint is not
>directly listed and therefore cannot be assumed to be openly licensed.
> 
>On Sat, 25 Jul 2020 at 17:35, David Wales <[4]daviewa...@disroot.org>
>wrote:
> 
>Dear all,
>As part of the [5]NSW Address Import, we have been relying (I think)
>upon the following explicit permission:
>[6]https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Gove
>rnment_Data
>However, the links mentioned in the permission no longer exist, as the
>LPI services have migrated to SIX maps.
>I'm just wanting to double-check that the permission still applies at
>the new location, and if so, does it apply to all the arcgis endpoints
>available in SIX maps? For example, the following:
>[7]https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAdd
>ress/MapServer/2
>Regards,
>David Wales
> 
>  ___
>  Talk-au mailing list
>  [8]Talk-au@openstreetmap.org
>  [9]https://lists.openstreetmap.org/listinfo/talk-au
> 
> References
> 
>1. 
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/3/query
>2. 
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>3. 
> https://www.spatial.nsw.gov.au/products_and_services/web_services/access_web_services
>4. mailto:daviewa...@disroot.org
>5. 
> https://wiki.openstreetmap.org/wiki/Australia_NSW_Property_and_Address_Import
>6. 
> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data
>7. 
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>8. mailto:Talk-au@openstreetmap.org
>9. https://lists.openstreetmap.org/listinfo/talk-au



-- 
Dion Moult


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

Re: [talk-au] Show your support of OpenStreetMap in our region: OSMF Application 

[Edoardo Neerhut]

Hi Sebastian,

Yes it took place and you can find the minutes here

.
We're just concluding a few things like the final list of people
participating and who will lead the working group.

The next meeting will be scheduled soon, so if you're interested, you can fill
your availability out her e.

Cheers,

Ed

On Sat, 25 Jul 2020 at 20:30, Sebastian S.  wrote:

> Hello all, late to the game.
> Did the meeting take place?
> Is there some outcome or summary of it?
>
> Cheers,
> Sebastian
>
> On 19 July 2020 5:17:40 pm AEST, Edoardo Neerhut 
> wrote:
>>
>> Hi again,
>>
>> Andrew informs me that the calendar invite link doesn't work. I'll send
>> out invites to everyone who puts 'Yes' next to the question about
>> volunteering on the working group, or feel free to respond to this email
>> requesting an invite.
>>
>> Cheers,
>>
>> Ed
>>
>> On Sun, 19 Jul 2020 at 16:49, Edoardo Neerhut  wrote:
>>
>>> Hi Oceania,
>>>
>>> *TLDR: Show your support for OpenStreetMap in Oceania by filling in this
>>> brief form
>>> ,
>>> and if you're interested, volunteering to help create an OSM Oceania
>>> working group.*
>>>
>>> The purpose of this email is to gather support and volunteers to
>>> establish a local chapter of the OpenStreetMap Foundation
>>>  (OSMF) in Oceania.
>>> OSGeo Oceania  has been supporting
>>> the application, and the benefits and objectives of this Local Chapter have
>>> been shared with the Australia
>>> 
>>> , New Zealand
>>> ,
>>> and Oceania
>>> 
>>> talklists in earlier emails and on the Maptime Oceania Slack
>>> .
>>> You can find the local chapter application that was submitted to the
>>> OSMF here
>>> 
>>> .
>>>
>>> *Application review*
>>>
>>> As part of the application review process, the OSMF Board, namely Joost
>>> Schouppe and Rory McCann, have already reached out to the community via
>>> various channels to gauge the level of community support for the
>>> application. While they received positive responses, the response was
>>> limited. I think we can do better.
>>>
>>> *Establishing an OpenStreetMap working group*
>>>
>>> One of the concerns raised by the OSMF Board and others is that OSGeo
>>> Oceania might not be truly representative of the OSM community. One
>>> solution to address this concern is to establish an OSM focused working
>>> group made up of representatives from across the region. While I hinted at
>>> this in May, I am now formally proposing that we establish a working group.
>>>
>>> The working group is a good solution because it will allow a wider range
>>> of voices from the region, without the requirement that those voices have
>>> any affiliation with OSGeo Oceania. At the same time, the working group
>>> would be able to benefit from the resources, structure, and conference
>>> platform that OSGeo Oceania has already established.
>>>
>>> *I propose the following:*
>>>
>>>
>>>1.
>>>
>>>An initial meeting of interested parties at 12:00 pm AEST/2pm New
>>>Zealand/Fiji time
>>>
>>> 
>>>this Thursday, July 23rd. The Google Meet link is in the calendar invite.
>>>If you're unable to make this time, let me know and I will arrange an
>>>additional meeting. Discussion via email is also acceptable.
>>>2.
>>>
>>>Formal establishment of an OSM working group and nomination of a
>>>leader to coordinate these efforts.
>>>3.
>>>
>>>Notification to OSGeo Oceania that this working group has been
>>>established.
>>>4.
>>>
>>>Notification to the OSMF that this working group has been
>>>established and that it will seek to understand and represent 
>>> stakeholders
>>>in Oceania's OSM community.
>>>5.
>>>
>>>Consultation period where the working group gathers input from
>>>throughout the region.
>>>6.
>>>
>>>Documentation of the working groups first priorities.
>>>
>>>
>>> The OSMF Board can then make a determination on whether to recognise
>>> OSGeo Oceania and by extension this working group as the local chapter for
>>> OpenStreetMap in Oceania.
>>>
>>> Thank you for your time and I hope you'll lend your support to this
>>> initiative.
>>>
>>> 

Re: [OSM-talk] Editing wiki asks for confirmation code?

[Michał Brzozowski]

Hi Skyler,
You can use any image hosting site to upload the image, and then post a
link here.
For instance: https://imgur.com/upload
Michał

On Sat, Jul 25, 2020 at 6:50 AM Skyler Hawthorne  wrote:

> I tried to post a screenshot, but the mailing list has a max size of 40
> KB,
> which seems very small.
>
> I am on a OnePlus 7T with OxygenOS 10.0.11.HD65AA. I've tried a couple of
> pages by clicking the pencil button, making my changes, and then hitting
> the Save button. This is when the text box appears that says "Confirmation
> Code."
>
> The same thing happens on both Firefox and Chrome.
> --
> Skyler
>
> On July 25, 2020 00:12:45 Skyler Hawthorne  wrote:
>
> > Hi, I'm posting here because I'm not sure where would be more
> appropriate.
> >
> > When I try to edit a wiki page, after I get to the preview page and
> enter a
> > description of the change, a text box pops up that just says
> "confirmation
> > code". I don't know if I'm supposed to get an email with a code or
> > something, but I never get one.
> >
> > What does it want?
> > --
> > Skyler
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it-lazio] incontro lunedì

[Marcello Pelato via Talk-it-lazio]

Mi spiace ma lunedì 27 luglio non posso.Sono dispiaciuto, perché avrei 
partecipato molto volentieri.Dopo tanto tempo.Sigh! Alla prossima___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [OSM-talk] Removing all signposts from relations

[Mark Wagner]

On Sat, 25 Jul 2020 18:14:14 +0200
pangoSE  wrote:

> Hi
> 
> Recently it was discussed whether to have signposts in route
> relations. I suggest we delete them from all relations by running a
> script. I se no loss of information doing that and a benefit to data
> consumers wanting to sort and calculate the length and height profile
> of the relation which I think should only contain unclosed ways
> belonging to the route.
> 
> What do you think?

I think that if software can't handle filtering out route members that
aren't of interest, it's defective and needs to be re-written.

(I think it's also likely to crash as soon as it encounters some of the
messes that make up real-world OSM data.)

-- 
Mark

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

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Martin Koppenhoefer]

sent from a phone

> On 25. Jul 2020, at 12:56, Manuel  wrote:
> 
>  Credo anche io si riferisca a iD, che in presenza di un waterway=riverbank 
> dà questo errore
> 
> 



spero che prima o poi si riesca di risolvere con questi edit automatici di iD, 
che spesso sono discutibili e contro il consenso della comunità.

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

Re: [Talk-es] Edit war about names in Basque speaking regions

[Jordi Miró Ferrer]

Hola,
El criterio usado en algunos de los changeset por Hart Beltza parece correcto 
si en el municipio aparecen placas con los nombres en ambos idiomas. Es decir, 
en name deben aparecer los dos nombres separados por una barra. Luego, habría 
que añadir las traducciones en name:eu y name:es. Catastro no siempre es lo 
oficial. Por ejemplo, la ciudad de València tiene el callejero en catalán de 
manera oficial, pero los de Catastro no lo han modificado y sigue saliendo en 
castellano. En principio, las placas deberían anteponerse a lo que diga el 
Catastro, a no ser que exista un error ortográfico en la placa. En este último 
cado, lo suyo sería corregirlo en OSM.

Saludos


De: Frederik Ramm 
Enviat el: divendres, 24 de juliol de 2020 22:39
Per a: talk-es@openstreetmap.org 
Tema: [Talk-es] Edit war about names in Basque speaking regions

Hi,

one user has changed several street names from the Spanish form to a
combined "Basque / Spanish" form. This has angered another user and
there have been fights about how these streets should be named.

I have blocked the user "Hartz Beltza" in
https://www.openstreetmap.org/user_blocks/3807 and requested that they
discuss the matter with the Spanish community before they continue. (I
have also requested from user H2Ox2 that he use better changeset comments.)

In OpenStreetMap it is very rare that we use dual languages in the
"name" tag but it *does* happen, for example in the bilingual
(Italian/German speaking) region of South Tyrol. There, both languages
are actually shown on the street signs. I don't know how this is in the
Basque regions. I am not saying you cannot do it but it required a broad
consensus that it is the right thing to do.

It is a decision that the Spanish community should be making, and the
DWG will then help enforce it.

Please continue this discussion in Spanish. I am providing an automated
translation of my message below.

Bye
Frederik
(DWG Ticket #202007241145)

Un usuario ha cambiado varios nombres de calles del formulario en
español a un formulario combinado "euskara / español". Esto ha enojado a
otro usuario y ha habido peleas sobre cómo se deben nombrar estas calles.

Bloqueé al usuario "Hartz Beltza" en
https://www.openstreetmap.org/user_blocks/3807 y solicité que
discutieran el asunto con la comunidad española antes de continuar.
(También solicité al usuario H2Ox2 que utilice mejores comentarios de
conjunto de cambios).

En OpenStreetMap es muy raro que usemos dos idiomas en la etiqueta
"nombre", pero * sucede *, por ejemplo, en la región bilingüe (italiano
/ alemán) del Provincia autónoma de Bolzano. Allí, ambos idiomas se
muestran en las señales de tráfico. No sé cómo es esto en las regiones
vascas. No digo que no pueda hacerlo, pero requirió un amplio consenso
de que es lo correcto.

Es una decisión que debe tomar la comunidad española, y el DWG ayudará a
hacerla cumplir.

Por favor continúe esta discusión en español.

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] Removing all signposts from relations

[Alex Dawn]

The PTv2 schema says to put all the route ways first in order, then the bus 
stops in order.

Maybe you can do a similar thing here and sort the route ways first and then 
the sign points.

Get Outlook for Android


From: Martin Koppenhoefer 
Sent: Saturday, July 25, 2020 9:04:11 PM
To: bartosom...@yahoo.it 
Cc: talk@openstreetmap.org 
Subject: Re: [OSM-talk] Removing all signposts from relations



sent from a phone

On 25. Jul 2020, at 20:33, Alberto Nogaro via talk  
wrote:


So if you do so, information is indeed lost.

+1


Otherwise I can’t see why should it difficult to data consumer to strip the 
unwanted information before processing the route.


+1





Unless the script preserves the information by storing it by alternative means, 
I would regard such a script as vandalism.

I agree and oppose this proposed automatic edit

Cheers Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Removing all signposts from relations

[Martin Koppenhoefer]

sent from a phone

> On 25. Jul 2020, at 20:33, Alberto Nogaro via talk  
> wrote:
> 
> So if you do so, information is indeed lost.
> 

+1

> Otherwise I can’t see why should it difficult to data consumer to strip the 
> unwanted information before processing the route.
> 


+1


>  
> 
> Unless the script preserves the information by storing it by alternative 
> means, I would regard such a script as vandalism.
> 

I agree and oppose this proposed automatic edit

Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-se] Naturreservat i OSM

[Bengt]

Hej,


Har dock en fundering/önskemål. Det finns ju även natura 2000 och 
riksintressen m.m.. Dessa hittar jag inte i OSM. Finns planer på att 
lägga in dessa (om de inte finns). En del områden är väldigt stora och 
överlappar varandra och då kanske olika färger skulle hjälpa till?
Naturvårdsveket har ju all info, men den datan går ju tyvärr vad jag vet 
inte att importera till Googlemaps på något smidigt sätt. Använder alla 
möjliga kartor för att hitta områdesgränser så att få allt på ett ställe 
vore toppen.


Kartorna i sig används av radioamatörer i en tävling som går ut på att 
ge sig ut i reservaten och där kontakta så många andra stationer som 
möjligt. Reservatgränser och skärningspunkter måste då letas upp. Man 
får sedan poäng efter ett visst system. Allt loggas och presenteras på 
vår hemsida. SMFF nedan.


MVH
Bengt
--
_
www.svenskasjoar.se 
-
smff.sk6ei.se 
-
JJRTVS - Nostalgi & historik 
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk] Removing all signposts from relations

[Alberto Nogaro via talk]

You could run a script to remove the signposts from the route relations. But, 
other than digging in the database history, there’s no script which could add 
them back (proximity of a sign to a route is not a valid criterion). So if you 
do so, information is indeed lost. Otherwise I can’t see why should it 
difficult to data consumer to strip the unwanted information before processing 
the route.

 

Unless the script preserves the information by storing it by alternative means, 
I would regard such a script as vandalism.

 

 

From: pangoSE  
Sent: 25 July 2020 18:14
To: talk@openstreetmap.org
Subject: [OSM-talk] Removing all signposts from relations

 

Hi

Recently it was discussed whether to have signposts in route relations. I 
suggest we delete them from all relations by running a script.
I se no loss of information doing that and a benefit to data consumers wanting 
to sort and calculate the length and height profile of the relation which I 
think should only contain unclosed ways belonging to the route.

What do you think?

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

Re: [OSM-talk] Removing all signposts from relations

[Tobias Knerr]

On 25.07.20 18:14, pangoSE wrote:
> Recently it was discussed whether to have signposts in route relations.
> I suggest we delete them from all relations by running a script.
> I se no loss of information

It loses the information whether or not a route is signed at a
particular signpost. Because, no, it is not the case that every signpost
will always contain directions for every route running closer than x
meters past it.

You may not personally care about that information, but that's a very
different argument. These are verifiable facts that someone found useful
enough to spend time mapping, and I don't think there's anything
inherently wrong with having them in OSM.

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

Re: [OSM-talk] Removing all signposts from relations

[Dave F via talk]

Where was the discussion. Do you have a link?

I think the relation of the 'route' should be purely the ways & if 
there's an actual requirement*, the signs should be included as a part 
of a super relation https://wiki.openstreetmap.org/wiki/Super-Relation


* Is there a requirement? Doesn't the route tell you where to go, & 
calculates how far to destination?


I'm slightly concerned a super relation would turn into a similar mess 
that PTv2 Stop Areas have become, where almost anything remotely near a 
transport stop is added to it.


DaveF

On 25/07/2020 17:14, pangoSE wrote:

Hi

Recently it was discussed whether to have signposts in route 
relations. I suggest we delete them from all relations by running a 
script.
I se no loss of information doing that and a benefit to data consumers 
wanting to sort and calculate the length and height profile of the 
relation which I think should only contain unclosed ways belonging to 
the route.


What do you think?

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


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

[OSM-talk] Removing all signposts from relations

[pangoSE]

Hi

Recently it was discussed whether to have signposts in route relations. I 
suggest we delete them from all relations by running a script.
I se no loss of information doing that and a benefit to data consumers wanting 
to sort and calculate the length and height profile of the relation which I 
think should only contain unclosed ways belonging to the route.

What do you think?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Scinder un immeuble

[osm . sanspourriel]

Bonjour,

Il est d'usage de mettre le lien l'objet en question sur la liste afin
de se faire une idée.

Car si l'immeuble a trois entrées mais qu'hormis ça, c'est un
parallélépipède rectangle, à quoi bon scinder ?

Les adresses sont représentées par des points, peu importe la
représentation du bâti en un ou trois objets.

Jean-Yvon

Le 25/07/2020 à 17:30, shikaruko - shikaruko-ryu...@gresille.org a écrit :

Bonjour,

Afin de rendre OSM correct vis à vis de la réalité, je souhaiterais
connaître s'il est envisageable de scinder un immeuble en différents
bâtiments. J'ai le cas d'un, où le tout est scindé en trois tours malgré
une apparence compacte avec des numéros différents.Merci d'avance.

Cordialement.



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

[OSM-talk-fr] Scinder un immeuble

[shikaruko]

Bonjour,

Afin de rendre OSM correct vis à vis de la réalité, je souhaiterais
connaître s'il est envisageable de scinder un immeuble en différents
bâtiments. J'ai le cas d'un, où le tout est scindé en trois tours malgré
une apparence compacte avec des numéros différents.Merci d'avance.

Cordialement.



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

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Volker Schmidt]

Grazie Manuel. Ho fatto confusione io.

Volker

On Sat, 25 Jul 2020, 17:09 Manuel,  wrote:

> Ho trovato il task sul sito di JOSM (18951
> ), ma si parla di
> water=riverbank, non di waterway.
>
> Manuel
>
> Ottieni BlueMail per Android 
> Il giorno 25 lug 2020, alle ore 16:42, Volker Schmidt 
> ha scritto:
>>
>> Adesso lo fa anche JOSM. Era quello la causa della mia domanda.
>>
>> On Sat, 25 Jul 2020, 12:56 Manuel, < mannivuw...@gmail.com> wrote:
>>
>>> Credo anche io si riferisca a iD, che in presenza di un waterway=riverbank
>>> dà questo errore
>>> Manuel
>>> Il 25/07/2020 10:10, Martin Koppenhoefer ha scritto:
>>>
>>>
>>>
>>> sent from a phone
>>>
>>> On 23. Jul 2020, at 15:17, Volker Schmidt 
>>>  wrote:
>>>
>>> Qualcuno che aveva seguito di più questa storia, potrebbe indicarmi con
>>> che procedura e quando waterway=riverbank è stato "depreceated".
>>>
>>>
>>>
>>> non mi risulta deprecated:
>>> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>>>
>>>
>>> ti riferisci ad iD?
>>>
>>> Ciao Martin
>>>
>>> ___
>>> Talk-it mailing 
>>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>  --
>>
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Manuel]

Ho trovato il task sul sito di JOSM (18951), ma si parla di water=riverbank, 
non di waterway.

⁣Manuel

Ottieni BlueMail per Android ​

Il giorno 25 lug 2020, 16:42, alle ore 16:42, Volker Schmidt 
 ha scritto:
>Adesso lo fa anche JOSM. Era quello la causa della mia domanda.
>
>On Sat, 25 Jul 2020, 12:56 Manuel,  wrote:
>
>> Credo anche io si riferisca a iD, che in presenza di un
>waterway=riverbank
>> dà questo errore
>> Manuel
>> Il 25/07/2020 10:10, Martin Koppenhoefer ha scritto:
>>
>>
>>
>> sent from a phone
>>
>> On 23. Jul 2020, at 15:17, Volker Schmidt 
>>  wrote:
>>
>> Qualcuno che aveva seguito di più questa storia, potrebbe indicarmi
>con
>> che procedura e quando waterway=riverbank è stato "depreceated".
>>
>>
>>
>> non mi risulta deprecated:
>> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>>
>>
>> ti riferisci ad iD?
>>
>> Ciao Martin
>>
>> ___
>> Talk-it mailing
>listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
>
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Volker Schmidt]

Adesso lo fa anche JOSM. Era quello la causa della mia domanda.

On Sat, 25 Jul 2020, 12:56 Manuel,  wrote:

> Credo anche io si riferisca a iD, che in presenza di un waterway=riverbank
> dà questo errore
> Manuel
> Il 25/07/2020 10:10, Martin Koppenhoefer ha scritto:
>
>
>
> sent from a phone
>
> On 23. Jul 2020, at 15:17, Volker Schmidt 
>  wrote:
>
> Qualcuno che aveva seguito di più questa storia, potrebbe indicarmi con
> che procedura e quando waterway=riverbank è stato "depreceated".
>
>
>
> non mi risulta deprecated:
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>
>
> ti riferisci ad iD?
>
> Ciao Martin
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] balisages club vosgien et GR

[Lucas Nussbaum]

Bonjour,

J'ai remarqué que le balisage club vosgien (ainsi que le balisage GR)
étaient maintenant disponibles sur OSM, avec le symbole des itinéraires
(https://wiki.openstreetmap.org/wiki/Key:osmc:symbol).

Voir par exemple ici:
https://hiking.waymarkedtrails.org/#route?id=9079172=15!48.1229!7.0881

Je pensais que ces balisages ne pouvaient pas être ajoutés, comme
expliqué dans https://forum.openstreetmap.fr/viewtopic.php?t=282

Est-ce que la portée de ce qui est autorisé est expliquée quelque part ?
Est-ce limité à certaines associations membres du club vosgien ?

Merci

Lucas

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

[Talk-at] landuse: line oder multipolygon?

[Patrick Strasser-Mikhail]

Hallo!

Eine Frage zu Stil und Praktikabilität:

Wenn ein detailliert gemaptes Gebiet ohne Lücken mit landuse oder 
gleichwertig getagt ist, dann stoßen ja immer exakt Flächen aneinander, 
entweder als geschlossene Linien oder als Multipolygone.


Es kommt aber immer wieder einmal vor, dass Ungenauigkeiten auftauchen, 
wie dass die aneinander stoßenden Linien nicht immer die gleichen Punkte 
verwenden, und dann bei Änderungen kleine Keile entstehen, wo dann halt 
nix ist, oder Überlappungen. Auch ein Klassiker ist, dass highway oder 
ähnliches sich Punkte mit der Linie teilt und dann das eine verschoben 
wird, aber ungewollt das andere mit verändert wird.


Mit Multipolygonen hätte man den Vorteil, dass idealerweise immer nur 
eine Linie eine Grenze darstellt, die von mehreren 
Multipolygon-Relationen verwendet wird. Nachteilig sehe ich aber, dass 
der Aufwand für Multipolygone deutlich höher ist, immer noch Fehler 
passieren können (irrtümliche einen highway als Multipolygon-Grenze 
gewählt), oder nicht-zusammgehörige Dingen mit einer gemeinsamen Linie 
"verbunden" werden.


Gibt es dazu - abgesehen von den technischen Ausführungen im Wiki (die 
sich darauf beziehen, dass ein Multipolygon halt notwendig ist, wenn es 
Löcher gibt und die Rolle "inner" benötigt wird) - bekannte Kriterien, 
wann eine geschlossene Linie und wann ein Multipolygon sinnvoll sind?


Und gibt es praktikable Werkzeuge, die es erleichtern, vom einen in das 
andere System zu kommen, oder auch problematische Flächen zu reparieren?
In JOSM kenn ich das Trennen von Linien (highway teilt Punkt mit 
landuse), aber das "mach mehrere geschlossene Linie zu Multipolygonen" 
hab ich noch nicht gefunden...


LG Patrick/trapicki
--
engineers motto: cheap, fast, good - choose any two

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

Re: [OSM-talk] Heresy - pure discussion

[John Whelan]

Looking at it from a TRA (Threat Risk Assessment) point of view 
OpenStreetMap is not totally dependent on one central database being up 
and working.


The primary database is fed by edits but if the database happens to get 
encrypted by Malware the backup and copies are still there.  The tiles 
on the tile server will still display, OSMAND will still work etc.


We strongly suspect that we are not running pure ISO standard SQL, which 
is fine but that does mean we need to take into account other linked 
databases so it would not just be the cost of the central database but 
many other servers and databases that would need to align and that is 
not trivial.  Some other users will have budgets and capacity to move 
others will not.  There is a lot of documentation tied back to the 
existing system which would need to be looked over.  Change management 
is not always simple.


For good database performance we need memory and lots of it so that 
rules out playing with SQL server express.


My concern that we weren't exactly mainstream with our database size has 
been reassured that there are other databases running on the same 
software that are larger.


Since we deal with a large number of new mappers who do odd things I get 
the impression that our procedures are robust and to be honest quite a 
lot of security is good procedures.


So thank you for your inputs, especially those who raised or addressed 
specific issues.


Cheerio John

Mateusz Konieczny via talk wrote on 2020-07-25 08:07:

And database size limit is just a start :)

It is artificially limited to 1G of RAM. I am curious how long planet 
import

with 1GB of RAM would run :)

Jul 25, 2020, 13:31 by jwhelan0...@gmail.com:

And as we start to fill the database with buildings even those
might not fit.

Thanks John

On Sat, Jul 25, 2020, 05:19 Hartmut Holzgraefe mailto:hart...@php.net>> wrote:

On 24.07.20 23:55, john whelan wrote:
> Microsoft SQL Server Express is a free limited version of
SQL server
> that may well do for many users.

reading express edition limitations I see:

* Maximum relational database size: 10GB

That would only be enough for the smallest of OSM regional
extracts ...

-- 
hartmut


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




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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Editing wiki asks for confirmation code?

[Skyler Hawthorne]

This doesn't look like CAPTCHA. It's just a text box with the word 
"Confirmation Code". It still happens with all ad blockers off. There are 
no requests to Google hosts, or any other non-OSM hosts.

--
Skyler
On July 25, 2020 08:13:10 Mateusz Konieczny via talk 
 wrote:

I would expect CAPTCHA. Can you try with adblock disabled

(including pihole, in-browser adblock, hosts file blocking etc)?


(yes, we are using recaptcha - if someone is capable of working on 
switching it to something


better - see https://github.com/openstreetmap/operations/issues/383

and https://github.com/openstreetmap/chef/issues/298


Jul 25, 2020, 06:10 by o...@dead10ck.com:

Hi, I'm posting here because I'm not sure where would be more appropriate.



When I try to edit a wiki page, after I get to the preview page and enter a 
description of the change, a text box pops up that just says "confirmation 
code". I don't know if I'm supposed to get an email with a code or 
something, but I never get one.




What does it want?

--

Skyler







___

talk mailing list

talk@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk


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


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

Re: [OSM-talk] Editing wiki asks for confirmation code?

[Mateusz Konieczny via talk]

I would expect CAPTCHA. Can you try with adblock disabled
(including pihole, in-browser adblock, hosts file blocking etc)?

(yes, we are using recaptcha - if someone is capable of working on switching it 
to something
better - see https://github.com/openstreetmap/operations/issues/383
and https://github.com/openstreetmap/chef/issues/298 

Jul 25, 2020, 06:10 by o...@dead10ck.com:

> Hi, I'm posting here because I'm not sure where would be more appropriate.
>
> When I try to edit a wiki page, after I get to the preview page and enter a 
> description of the change, a text box pops up that just says "confirmation 
> code". I don't know if I'm supposed to get an email with a code or something, 
> but I never get one.
>
> What does it want?
> --
> Skyler
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Heresy - pure discussion

[Mateusz Konieczny via talk]

And database size limit is just a start :)

It is artificially limited to 1G of RAM. I am curious how long planet import
with 1GB of RAM would run :)

Jul 25, 2020, 13:31 by jwhelan0...@gmail.com:

> And as we start to fill the database with buildings even those might not fit.
>
> Thanks John
>
> On Sat, Jul 25, 2020, 05:19 Hartmut Holzgraefe <> hart...@php.net> > wrote:
>
>> On 24.07.20 23:55, john whelan wrote:
>>  > Microsoft SQL Server Express is a free limited version of SQL server 
>>  > that may well do for many users.
>>  
>>  reading express edition limitations I see:
>>  
>>  * Maximum relational database size: 10GB
>>  
>>  That would only be enough for the smallest of OSM regional extracts ...
>>  
>>  -- 
>>  hartmut
>>  
>>  ___
>>  talk mailing list
>>  >> talk@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk
>>

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

Re: [Talk-se] Diverse frågor kring öar

[Essin]

Hej!

Ett delsvar på fråga 2: place=locality som används för Jättholmarna nu är
på sätt och vis en generell "i brist på bättre"-tagg. Den renderas i
standardrenderingen på osm.org men bara med liten text från zoomnivå 16 och
uppåt. En multipolygon för de ingående öarna med taggen place=archipelago
[1] är en mer specifik taggning för det här fallet. place=archipelago
renderas inte alls i standardrenderingen för närvarande, men det kommer
antagligen att ändras förr eller senare. [2] Objekten kommer däremot upp i
sökresultaten, se t ex [3].

Ett sidospår till fråga 3: Du har kanske redan märkt att kustlinjerna
renderas om långsammare än andra OSM-objekt. Mer info om det finns på [4].

[1] https://wiki.openstreetmap.org/wiki/Tag:place=archipelago
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/3394
[3] https://www.openstreetmap.org/relation/10692170
[4] https://wiki.openstreetmap.org/wiki/Coastline

Vänliga hälsningar
Essin

Den tors 23 juli 2020 kl 20:55 skrev Aron Bergman :

> Hej,
> Har under sommaren tagit båten till några lokala öar och passade på att gå
> lite
> stigar med OSMTracker och har suttit och lagt in det nu. Det har uppstått
> en del
> frågor som jag hoppades att någon här skulle kunna svara på, hade säkert
> kunnat
> sökt mig till infon, men det känns bättre att fråga personer som har
> erfarenhet av
> OSM.
>
> 1. På Gran finns en fyr och i närheten av denna finns som en träplatta
> byggd. Min
> far påstod att den skulle fungera som helikopterplatta, förmodligen
> för att serva
> fyren, men hittar ingen information om det online. Jag lade in plattat
> i OSM, men
> den är helt omärkt. Hur tycker ni att den ska mappas? Ska den mappas över
> huvud taget? Hittade inte något sätt att märka den som just träplatta och
> helikopterplatta kändes inte riktigt rätt heller (jag kan ju inte med
> säkerhet säga att
> det är det som den ska användas till). Plattan finns här [1], men hittas
> inte av
> "Query here", syns dock i JOSM.
>
> 2. Var också ut på Jättholmarna och gick en sväng och noterar nu när
> jag lägger in
> stigen att det inte står Jättholmarna någonstans på OSM-kartan, endast
> Österön
> och Västerön. Jag ser i JOSM att det finns en nod med namnet Jättholmarna,
> men det renderas inte. Finns det något sätt att komma runt det?
> Känner inte någon som har stuga på någon av ödelarna som säger att de har
> stuga på Öster/Västerön. [2]
>
> 3. När jag lade in stigen på Jättholmarna så märkte jag att kustlinjen
> ligger lite fel
> på en del ställen, så det ser ut som att stigen går ut en bit i
> vattnet ibland. Jag ska
> ut dit igen och mappa en brygga som vi byggt om efter att isen
> förstörde den förra,
> så tänkte passa på att fixa kustlinjen då. Har funderat på att försöka
> "flygfota" själv
> med en drönare. Jag tänkte att om man kan få in ett par fasta föremål
> (typ utmärkande stenar i vattnet) så borde man kunna lägga in de i JOSM och
> sedan tracea bryggan utifrån fotona. Är det någon här som testat någonting
> liknande innan? Det kanske inte är så lätt som jag tänker mig.
>
> [1] https://www.openstreetmap.org/way/828923027
> [2] https://www.openstreetmap.org/node/919814869
>
> Hälsningar
> Aron Bergman
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-au] NSW LPI Data

[David Wales]

Hmm...
We might have a problem then, because we've been using the following
endpoint to generate our address points:
https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/3/query

I was hoping to move to using the following instead, as it provides
better locations for the addresses in some cases:
https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2

However, if we don't actually have permission for these endpoints, we're
going to either need to get permission somehow, or revert and restart
with the correct endpoint! :(

Some guidance would be good here!

Regards,
David Wales

On 25/7/20 5:45 pm, Andrew Harvey wrote:
> It should still apply, but as always only the services listed
> at 
> https://www.spatial.nsw.gov.au/products_and_services/web_services/access_web_services
>  are
> covered, the Property Address endpoint is not directly listed and
> therefore cannot be assumed to be openly licensed.
>
> On Sat, 25 Jul 2020 at 17:35, David Wales  > wrote:
>
> Dear all,
>
> As part of the NSW Address Import
> 
> ,
> we have been relying (I think) upon the following explicit permission:
>
> 
> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data
>
> However, the links mentioned in the permission no longer exist, as
> the LPI services have migrated to SIX maps.
> I'm just wanting to double-check that the permission still applies
> at the new location, and if so, does it apply to all the arcgis
> endpoints available in SIX maps? For example, the following:
> 
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>
> Regards,
> David Wales
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
>



signature.asc
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Heresy - pure discussion

[john whelan]

And as we start to fill the database with buildings even those might not
fit.

Thanks John

On Sat, Jul 25, 2020, 05:19 Hartmut Holzgraefe  wrote:

> On 24.07.20 23:55, john whelan wrote:
> > Microsoft SQL Server Express is a free limited version of SQL server
> > that may well do for many users.
>
> reading express edition limitations I see:
>
> * Maximum relational database size: 10GB
>
> That would only be enough for the smallest of OSM regional extracts ...
>
> --
> hartmut
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Manuel]

Credo anche io si riferisca a iD, che in presenza di un waterway=riverbank dà 
questo errore
Manuel
Il 25/07/2020 10:10, Martin Koppenhoefer ha scritto:



sent from a phone


On 23. Jul 2020, at 15:17, Volker Schmidt  wrote:

Qualcuno che aveva seguito di più questa storia, potrebbe indicarmi con che procedura e 
quando waterway=riverbank è stato "depreceated".



non mi risulta deprecated:
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank


ti riferisci ad iD?

Ciao Martin

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


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

Re: [talk-au] Working with local government

[Sebastian S.]

I think in the US the tiger import used such tags with the aim to remove them 
once the item has been checked. A massive and still ongoing effort from what I 
heard.

On 20 July 2020 10:17:25 pm AEST, Andrew Harvey  
wrote:
>On Mon, 20 Jul 2020 at 12:33, David Wales 
>wrote:
>
>> Is there any reason against using a custom tag as a linking key?
>>
>> e.g. some_import_object_id=123456
>>
>> Then when you need to update the data, you can match the key in OSM
>with
>> the key in the source data.
>
>
>It can be a deterrent to mappers, they may see these external ids and
>think
>oh I don't understand that, maybe it's special and I shouldn't touch
>it,
>maybe it is owner by someone else and they update it directly.
>
>Similar to what Mateusz said, if the community can't verify it, how do
>we
>know it's right? What should we do if things change on the ground? How
>do
>we know if the ID still applies to the new tag? In my opinion a better
>solution for a private linkage is for the 3rd party database to point
>directly to the OSM node/way/relation ID. The external database should
>monitor for changes to those IDs and then review after each change if
>the
>linkage is correct or needs changing.
>
>Though still the private ID method has been used for imports of the
>past,
>and I'm not saying it can't be used, but there are disadvantages and
>valid
>concerns.
>
>On Mon, 20 Jul 2020 at 14:08, Greg Dutkowski 
>wrote:
>
>> Hi,
>> I was thinking of using the ref tag to store the council ID for the
>> object, and then the council could use the OSMID in their database.
>> What I was looking for was tools or approaches for keeping the two in
>> sync. The foreign keys in each system are part of that.
>> The conflation tools Andew Harvey pointed to may be a way to go.
>> OSM is so big and diverse it is hard to get your head around all of
>the
>> possibilities, so contacts with people who are making conflation work
>would
>> be ideal.
>>
>
>I haven't tried those tools before, but my outsider view is that they
>are
>too low level and not mature. I would love to see something similar to
>Maproulette or Tasking Manager from an ease of use and non-technical
>setup
>point of view but for maintaining linkages with external datasets.
>
>I wrote recently about a conflation I did to compare government traffic
>lights data https://www.openstreetmap.org/user/aharvey/diary/393663 and
>I
>avoided any coding in that process.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Show your support of OpenStreetMap in our region: OSMF Application 

[Sebastian S.]

Hello all, late to the game.
Did the meeting take place?
Is there some outcome or summary of it?

Cheers,
Sebastian

On 19 July 2020 5:17:40 pm AEST, Edoardo Neerhut  wrote:
>Hi again,
>
>Andrew informs me that the calendar invite link doesn't work. I'll send
>out
>invites to everyone who puts 'Yes' next to the question about
>volunteering
>on the working group, or feel free to respond to this email requesting
>an
>invite.
>
>Cheers,
>
>Ed
>
>On Sun, 19 Jul 2020 at 16:49, Edoardo Neerhut 
>wrote:
>
>> Hi Oceania,
>>
>> *TLDR: Show your support for OpenStreetMap in Oceania by filling in
>this
>> brief form
>>
>,
>> and if you're interested, volunteering to help create an OSM Oceania
>> working group.*
>>
>> The purpose of this email is to gather support and volunteers to
>establish
>> a local chapter of the OpenStreetMap Foundation
>>  (OSMF) in Oceania.
>OSGeo
>> Oceania  has been supporting the
>> application, and the benefits and objectives of this Local Chapter
>have
>> been shared with the Australia
>>
>,
>> New Zealand
>> ,
>and
>> Oceania
>
>> talklists in earlier emails and on the Maptime Oceania Slack
>>
>.
>> You can find the local chapter application that was submitted to the
>OSMF
>> here
>>
>.
>>
>> *Application review*
>>
>> As part of the application review process, the OSMF Board, namely
>Joost
>> Schouppe and Rory McCann, have already reached out to the community
>via
>> various channels to gauge the level of community support for the
>> application. While they received positive responses, the response was
>> limited. I think we can do better.
>>
>> *Establishing an OpenStreetMap working group*
>>
>> One of the concerns raised by the OSMF Board and others is that OSGeo
>> Oceania might not be truly representative of the OSM community. One
>> solution to address this concern is to establish an OSM focused
>working
>> group made up of representatives from across the region. While I
>hinted at
>> this in May, I am now formally proposing that we establish a working
>group.
>>
>> The working group is a good solution because it will allow a wider
>range
>> of voices from the region, without the requirement that those voices
>have
>> any affiliation with OSGeo Oceania. At the same time, the working
>group
>> would be able to benefit from the resources, structure, and
>conference
>> platform that OSGeo Oceania has already established.
>>
>> *I propose the following:*
>>
>>
>>1.
>>
>>An initial meeting of interested parties at 12:00 pm AEST/2pm New
>>Zealand/Fiji time
>>   
>
>>this Thursday, July 23rd. The Google Meet link is in the calendar
>invite.
>>If you're unable to make this time, let me know and I will arrange
>an
>>additional meeting. Discussion via email is also acceptable.
>>2.
>>
>>Formal establishment of an OSM working group and nomination of a
>>leader to coordinate these efforts.
>>3.
>>
>>Notification to OSGeo Oceania that this working group has been
>>established.
>>4.
>>
>>Notification to the OSMF that this working group has been
>established
>>and that it will seek to understand and represent stakeholders in
>Oceania's
>>OSM community.
>>5.
>>
>>Consultation period where the working group gathers input from
>>throughout the region.
>>6.
>>
>>Documentation of the working groups first priorities.
>>
>>
>> The OSMF Board can then make a determination on whether to recognise
>OSGeo
>> Oceania and by extension this working group as the local chapter for
>> OpenStreetMap in Oceania.
>>
>> Thank you for your time and I hope you'll lend your support to this
>> initiative.
>>
>> Edoardo Neerhut
>>
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Heresy - pure discussion

[Hartmut Holzgraefe]

On 24.07.20 23:55, john whelan wrote:
Microsoft SQL Server Express is a free limited version of SQL server 
that may well do for many users.


reading express edition limitations I see:

* Maximum relational database size: 10GB

That would only be enough for the smallest of OSM regional extracts ...

--
hartmut

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

Re: [Talk-it] [talk-it] waterway=riverbank deprecated

[Martin Koppenhoefer]

sent from a phone

> On 23. Jul 2020, at 15:17, Volker Schmidt  wrote:
> 
> Qualcuno che aveva seguito di più questa storia, potrebbe indicarmi con che 
> procedura e quando waterway=riverbank è stato "depreceated".


non mi risulta deprecated:
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank


ti riferisci ad iD?

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

Re: [talk-au] NSW LPI Data

[Andrew Harvey]

It should still apply, but as always only the services listed at
https://www.spatial.nsw.gov.au/products_and_services/web_services/access_web_services
are
covered, the Property Address endpoint is not directly listed and therefore
cannot be assumed to be openly licensed.

On Sat, 25 Jul 2020 at 17:35, David Wales  wrote:

> Dear all,
>
> As part of the NSW Address Import
> ,
> we have been relying (I think) upon the following explicit permission:
>
>
> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data
>
> However, the links mentioned in the permission no longer exist, as the LPI
> services have migrated to SIX maps.
> I'm just wanting to double-check that the permission still applies at the
> new location, and if so, does it apply to all the arcgis endpoints
> available in SIX maps? For example, the following:
>
> https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2
>
> Regards,
> David Wales
> ___
> 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

[talk-au] NSW LPI Data

[David Wales]

Dear all,

As part of the NSW Address Import
,
we have been relying (I think) upon the following explicit permission:

https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data

However, the links mentioned in the permission no longer exist, as the
LPI services have migrated to SIX maps.
I'm just wanting to double-check that the permission still applies at
the new location, and if so, does it apply to all the arcgis endpoints
available in SIX maps? For example, the following:
https://maps.six.nsw.gov.au/arcgis/rest/services/sixmaps/PropertyAddress/MapServer/2

Regards,
David Wales


signature.asc
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Découpage administratif à Paris, les conseils de quartier

[Philippe Verdy]

Hmmm... les conseils de quartiers existent en théorie, cependant ce sont
des structures autonomes (associatives), dont le rôle est consultatif. Et
souvent les communes conservent leur propres définitions des secteurs. Ceci
peut aussi se découper différememnt avec la participation citoyenne
locale ou les conseils (également consultatifs) de la jeunesse. PArfois ces
structures font "doublon" ou se concurrencent entre elles avec des avis
différents. Au final toute la décision revient au conseil municipal qui
s'en tient à son découpage administratif (parfois concerté avec les autres
communes de l'EPCI pour gérer des services communs que les autres
communes ne gèrent pas toutes elles-mêmes).
De plus le découpage des conseils de quartiers est flou, pas strict. Ils
sont compétents aussi sur leur voisinage et il n'y a pas de réelle
assignation de ceux qui peuvent y participer (même pas la résidence dans la
commune elle-même, il faut juste se sentir concerné par ce qui s'y passe,
d'une façon ou d'une autre, ce sont des volontaires qui entrent dans cette
démarche et se réunissent de temps en temps). Au final ces conseils sont un
peu comme des assos, elles aussi sans limites territoriales absolues. Et
d'ailelrus nombre de ces conseils sont établis en tant qu'asso et ne
peuvent pas mettre de restriction d'accès à leurs adhésions, autre que leur
réglement intérieur, le fonctionnement de l'assemblée, la cotisation, la
participation aux frais, et désigner un bureau de quelques personnes
responsables (en particulier le trésorier qui tient les comptes pour tous
et le secrétaire qui se charge de collecter ce qui est du courrier ou
rapporter les minutes des réunions et les archiver ou diffuser; le
président lui ne décide pas grand chose, il ne fait que diriger un peu les
débats mais ce n'est pas forcément lui qui les anime ni en concocte les
sujets à traiter, ni forcément lui qui va ensuite négocier avec la commune
ou d'autres intervenants ; le plus gros étant fait au bon vouloir des
membres qui seulement en discutent entre eux et où chacun apporte son
expérience ou ses compétences propres).
Si ce que réalise le conseil de quartier est de qualité suffisante, la
commune en tiendra compte... ou pas. La décision au final sera
rediscutée au conseil municipal qui cependant aura des "billes" dans les
mains pour motiver ou modifier ses projets.

Le sam. 18 juil. 2020 à 01:35, Jérôme Amagat  a
écrit :

> Les quartiers administratifs ça sert à quoi ?
> Ils ont des limites fixées depuis plus de 150 ans et ont dans leur nom le
> mot "administratif" mais tout ce que je trouve apres une brève recherche
> c'est qu"ils ont chacun un poste de police...(c'est une ancienne division
> de la préfecture de police ?)
> Donc j'ai l'impression qu'il n'ont rien à faire dans osm avec
> boundary=administrative admin_level=10.
> Les conseils de quartier ont aucun pouvoir non plus :) seulement
> consultatif mais je trouve plus logique que pour eux il y ait
> boundary=administrative admin_level=10.
> Par contre pour les quartiers administratifs, il faudrait savoir a quoi
> ils servent pour savoir quoi mettre dans boundary=*, peut être "historic"...
>
> nb : Je ne suis pas parisien.
> ___
> 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

Re: [talk-au] How do you tag a registered club?

[Graeme Fitzpatrick]

On Thu, 16 Jul 2020 at 18:04, Andrew Davidson  wrote:

> On 16/7/20 9:49 am, Bren Barnes wrote:
> > Morning, apparently it's amenity=licensed_club according to tagging
> > guidelines.
> >
> >
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Licensed_Club
> >
>
> Thanks for that. A lot less painful than I was expecting.
>

Catching up after a week away ...

Unfortunately though, amenity=licensed_club or club=veterans don't render,
so you still need a building=yes or similar to add them to :-(

Thanks

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