Re: [Talk-de] routing.openstreetmap.de

[Tobias]

Hi,

Danke für die Info...
Kann das Routing was besonmderes???

Gruß

  Originalnachricht  
Von: michael spreng
Gesendet: Samstag, 30. Dezember 2017 00:45
An: talk-de@openstreetmap.org
Antwort an: Openstreetmap allgemeines in Deutsch
Betreff: [Talk-de] routing.openstreetmap.de


Hallo

Unter https://routing.openstreetmap.de/ gibt es nun weltweites  
Routing mit OSRM — mit Auto-, Fussgänger- und Bike-Profil. Die  
Server sind von FOSSGIS gesponsert und wurden von mir in den letzten  
paar Wochen eingerichtet. Der eine Server rechnet basierend auf dem  
jeweils aktuellen OSM-planet die Graphen aus, während der andere die  
Daten ausliefert. Der Update-Zyklus ist im Moment etwa ein Tag.  
Probiert es doch mal aus.


Beste Grüsse
Michael

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





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

Re: [Talk-us] Changing

[Albert Pundt]

It also allows for ref:legislative to be used (much like ref:penndot
throughout Pennsylvania) in states that still use these separate
legislative routes.

On Fri, Dec 29, 2017 at 8:49 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> BTW, I'm all for your old_ref_legislative -> old_ref:legislative
> proposal.  It seems it would harmonize tags in the East and West (of the
> USA).
>
> Briefly (my reasoning is):  combining tagging conventions with tagging
> conventions growth = growth in OSM.  It is surprising how resolving small
> syntax and semantics blurs like these truly helps everything!
>
> Steve




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

Re: [Talk-us] Potential vandalism in Northern California (Pokémon Go?) (Andy Townsend)

[OSM Volunteer stevea]

Before we (Albert, Andy, others) discuss changing how we tag legislative 
references, OSM might reflect on the fact that it has a history (as of course 
any import does, whether widely discussed or done in the dead of night by a 
single volunteer).  Simultaneously, what we call a leisure=park blends and 
mingles with protected_area, this is a wide-open, worldwide discussion.  Moving 
targets, fuzzy definitions, changing and newer semantics:  these are relatively 
smaller problems in OSM.  Yet, solving these simultaneously is part of the cost 
of OSM growing.

Major is the difference between landuse and landcover.  (The root of many 
misunderstandings which turn into disagreements).  We continue and continue to 
discuss this sticky topic, in my opinion because it is easy for well-meaning 
people who have misunderstandings as to landuse and landcover continue to 
disagree, that is a predictable outcome of such semantic blurring.  As 
volunteers edit with our geo-editors using multiple and more-visual layers 
(satellite and/or aerial imaging), this semantic blurriness likely continues.

Sticking to the definitions which evolve in our (relatively slow-moving and 
hence with a stickier consensus) wiki both has worked and does work.  Let's 
keep doing that.

While I understand Pokémon Go vandalism (PGV) happens in OSM (and I ask neither 
forgiveness nor permission as I deftly remove it, as I know it when I see it), 
and that likely means a "watch search" or "heightened awareness" for PGV can 
cause some surprising understandings/interpretations/visual parsings of 
leisure=park when seen.  These are different, though related, topics.

When waters get muddy like this, talking about them first in a forum like here 
helps:

1)  Let's agree that what our wiki says in leisure=park defines what we mean by 
"a park is a park, like this, even if it doesn't seem like that is what other 
parks look like, exactly."  In other words, what OSM says is a "park" is a 
short definition, but it is an elastic one which encompasses a big and generous 
solution space to include parks.

2)  Landuse is not landcover and vice versa.

SteveA
California

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

Re: [OSM-talk] shop windows on differnt streets

[Dave F]

There aren't multiple entrances in Catonano's examples.

Shops on the corner of two streets is common across the globe.

Are you suggesting these places have multiple postal addresses?

On 29/12/2017 22:28, Martin Koppenhoefer wrote:


Having housenumbers for every entrance and potential entrance is 
extremely common in Italy for example. The usual solution is to add 
nodes with the street name and housenumber at every such point, plus a 
node somewhere inside the area for the POI (shop, etc.) with the POI 
tags and the address they use (e.g. Via Cavour 107, or Via Cavour 
103-109, or Via Cavour 103/105/107/109, or even Via Cavour 
103;105;107;109).


If you want to explicitly tell which numbers belong to the POI I think 
it is better to draw an approximate polygon for the POI (i.e. you can 
see from the polygon which address nodes belong to it) rather than 
grouping them by a relation, for several reasons:


- easier to verify visually
- adds more information (size, shape, topology)
- easier to modify
- easier to understand
- requires less advanced editing tools
- likely more stable because of the previous points


cheers,
Martin




___
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-ph] NCR meet-up/get together?

[Erwin Olario]

Maning proposed for an informal get together soon [0]. Would you folks be
interested in joining ?

[0]: https://osmph-chat.herokuapp.com/
-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-se] Församlingshem: vilka taggar finns och hur ska man använda dem?

[Erik Johansson]

2017-12-28 22:02 GMT+01:00 Essin 
>
> När jag tog upp det här i #osm på IRC kom några invändningar mot den
> första taggningen, för det första eftersom församlingshemmens verksamhet
> kanske inte är tillräckligt utåtriktad för att räknas som community_centre,
> för det andra för att "parish hall" i Storbritannien ofta syftar på något
> snarare motsvarande sockenstuga, alltså den icke-kyrkliga betydelsen av
> "parish", och för det tredje för att ordvalet passar dåligt på samfund som
> inte har territoriella församlingar. Det visade sig också att den är
> ifrågasatt på wikin [5]. Frågan är då: ska man anse att taggningen ändå är
> en förbättring och använda den med förhoppning om att den ersätts av något
> ännu bättre senare, eller ska man avstå från att använda den?
>
>
Jag är av den fasta åsikten att OSM taggar måste vara generella och
specifika, därför är community centre den bästa taggningen, med extra
taggning som särskiljer det från andra sådana ställen. Församlingshem, ABF
hus och bygdegårdar fungerar som knutpunkter i många samhällen alltså ett
community, man vill dessutom gärna kunna hitta dit men  inte till
organisationen som driver det.

Kör event_venue om du verkligen måste ha något som redan är definierat, om
inte det så tycker jag det kan vara en bra idé att köra på den svenska
termerna som värde till communit_centre= eftersom de är någorlunda
väldefinierade i vår kulturellasfär. Det med lite Wiki dokumentation är
perfekt.

office=* känns helt fel, förutom när det verkligen är ett kontor som är
huvudfunktionen (vilket jag aldrig stött på vilket naturligtvis färgar min
åsikt).

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

[Talk-de] routing.openstreetmap.de

[michael spreng]

Hallo

Unter https://routing.openstreetmap.de/ gibt es nun weltweites Routing 
mit OSRM — mit Auto-, Fussgänger- und Bike-Profil. Die Server sind von 
FOSSGIS gesponsert und wurden von mir in den letzten paar Wochen 
eingerichtet. Der eine Server rechnet basierend auf dem jeweils 
aktuellen OSM-planet die Graphen aus, während der andere die Daten 
ausliefert. Der Update-Zyklus ist im Moment etwa ein Tag. Probiert es 
doch mal aus.


Beste Grüsse
Michael

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

Re: [Talk-GB] Importing Shell fuel stations

[Mick Orridge]

On 28/12/17 22:33, Warin wrote:

On 29-Dec-17 07:28 AM, Mark Goodge wrote:



On 28/12/2017 19:31, Lester Caine wrote:

Get the return address right ...

On 28/12/17 16:12, Colin Spiller wrote:
I've been adding postcodes in the Bradford BD area using Robert & 
gregrs

useful tools. I've just noticed that the Shell station at the Rooley
Lane / Rooley Avenue junction BD5 8JR is now reported as having an
incorrect postal unit (the final two letters of the postcode). This
postcode appears widely on the internet for this site, but the RM
postcode finder thinks it should be Rooley Avenue, BD6 1DA.


PAF file has ...
Shell Filling Station
Rooley Avenue
BRADFORD
BD6 1DA

and BD5 8JR is not listed having been deleted in 2009
http://checkmypostcode.uk/bd58jr so the real problem is does one leave
the faulty postcode in place because we can't use the PAF data or do we
validate postcodes against the codepoint database and remove those that
are not listed


It's an interesting conundrum, on several levels. We can certainly 
validate against Codepoint Open or the ONSPD, as these are open data. 
So if they say the postcode is impossible (because it's defunct), 
then we can definitely delete it if we want to.


Replacing it with the correct postcode, though, is harder. We'd need 
a source that isn't derived from PAF. But Googling for this 
particular station, all the sources have the old, incorrect postcode 
- even Google itself! (I would expect they're all using the Shell 
data, of course).


So that leaves us with three options, at least initially:

1. Leave it as is. We know it's wrong, but it's consistent with every 
other source, and it's from the only canonical source.


2. Replace it with the right one. More useful, but potentially risky 
from a licensing perspective.


3. Delete it and leave the entry with no postcode. Probably the best 
we can do as far as accuracy is concerned (in line with the general 
principle that data is better missing than wrong, if it can't be 
right), and avoids any licence conflict. But this is the least useful 
for users of the data (since, in this case, even the wrong postcode 
will identify the location in practice - for obvious reasons, Royal 
Mail will deliver to defunct postcodes long after they have been 
deleted, and many sat-navs will work with defunct postcodes too).


Maybe the best solution is to leave it alone for now, and see if we 
can persuade Shell to fix it. Deleting the postcode risks it being 
re-added by someone else who spots its absence and decides to be 
helpful, without realising that if they use the RM postcode finder to 
validate it that isn't compatible with OSM's licence.


Usually a note is used to make comments to other mappers. In this case 
a note to say that post code xxx is defunct would explain the 
situation. Possibly a tag 'defunct:postcode=xxx would also be 
explanatory.


Could the post code be derived from surrounding features?
I don't know how detailed the post codes there are .. but if features 
in OSM surrounding it were of the same post code (and correct) then 
they could be used to derive the post code?
The ONS postcode file (Open Government Licence other than BT postcodes 
for NI) for August 2017 (download here:- 
https://ons.maps.arcgis.com/home/item.html?id=1e4a246b91c34178a55aab047413f29b) 
holds terminated postcodes. It's entry for BD5 8JR shows a terminated 
date of 2009 06. I guess the replacement postcode could be narrowed down 
using the date introduced field along with perhaps the OA01 field (2001 
census output area) plus easting and northing.



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

Re: [Talk-it] Trinceroni

[Martin Koppenhoefer]

sent from a phone

> On 29. Dec 2017, at 19:20, demon.box  wrote:
> 
> military=bunker
> bunker_type=observation
> disused=yes
> start_date=1915
> end_date=1945
> historic=yes


bo, cosa vogliono dire i tag start_date e end_date? Non esiste più, oppure non 
viene più utilizzato? Sarebbe ancora utilizzabile? Non si può più osservare? 
Non protegge più contro un nemico? Non ci sono più nemici? Disused al solito 
significa non attualmente in uso, ma riattivabile con poco sforzo (senno è 
“abandoned”).
historic=yes?

Generalmente viene sconsigliato disused=yes a favore di disused:.

Non lo so, leggendo i tag e conoscendo la storia, 1915-1945 insieme a disused 
mi consentono di immaginare il contesto, ma probabilmente per un computer non 
sarebbe chiaro questo tagging. Inizierei una discussione sulla mailing list 
tagging, forse si arriva a qualcosa di meglio.

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

Re: [Talk-it] Trinceroni

[Martin Koppenhoefer]

sent from a phone

> On 29. Dec 2017, at 10:39, Cascafico Giovanni  wrote:
> 
> Se c'è una porta, come mi par di vedere da alcune foto, direi 
> barrier=sally_port e relativo access,  altrimenti sezionerei la way e 
> toglierei il covered dalla parte scoperta.


sally port quando ci sono due porte, con uno stanzino in mezzo.


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

Re: [OSM-talk] shop windows on differnt streets

[Martin Koppenhoefer]

sent from a phone

> On 27. Dec 2017, at 18:36, Catonano  wrote:
> 
> There s this shop that has shop windows on 2 streets
> https://imgur.com/a/icpwJ
> 
> Some of its shop windows have street numbers. as shown here
> https://imgur.com/a/ny08t
> 
> This is  a quite common case, as you can see here
> https://photos.app.goo.gl/Vr2vKuqr1S5hjf772
> 
> Some have their shop windows separated by building entrances or a different 
> shop windows
> 
> How do I map these ?


Having housenumbers for every entrance and potential entrance is extremely 
common in Italy for example. The usual solution is to add nodes with the street 
name and housenumber at every such point, plus a node somewhere inside the area 
for the POI (shop, etc.) with the POI tags and the address they use (e.g. Via 
Cavour 107, or Via Cavour 103-109, or Via Cavour 103/105/107/109, or even Via 
Cavour 103;105;107;109). 

If you want to explicitly tell which numbers belong to the POI I think it is 
better to draw an approximate polygon for the POI (i.e. you can see from the 
polygon which address nodes belong to it) rather than grouping them by a 
relation, for several reasons:

- easier to verify visually 
- adds more information (size, shape, topology)
- easier to modify
- easier to understand 
- requires less advanced editing tools
- likely more stable because of the previous points 


cheers,
Martin 


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

Re: [Talk-it] cimiteri in Italia

[Martin Koppenhoefer]

sent from a phone

> On 29. Dec 2017, at 17:22, Elena ``of Valhalla''  
> wrote:
> 
> A quanto ho capito, cemetery è il cimitero nuovo stile (che qui da noi
> ha imposto Napoleone) fuori dal nucleo abitato con tutte le tombe messe
> ben in ordine con confini chiaramente segnati, mentre graveyard è quello
> vecchio stile che era tipicamente dentro al nucleo abitato (vicino alla
> chiesa, appunto), in cui capita che le tombe rimangano sovrapposte le
> une alle altre e cose del genere.


+1, esattamente, “antico” non era nel senso degli antichi romani.

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

Re: [Talk-ar] Interpolación Incorrecta

[Werner Horsch]

Es correcto Jorge, si ingresas a nuestro foro
https://forum.openstreetmap.org/viewtopic.php?id=60742   vas a ver
un post relativo al partido de Lanús. Castellaro tiene ediciones masivas de
baja calidad, pero tb tiene sus cosas buenas, su fuerte no es la edición
del mapa jajajaja

Algunos los corregí, pocos comparados con los que hay mal. Podes borrar los
que están mal si te molestan al editar, o volver a editarlos para
corregirlos si te es más sencillo.

Recuerdo haber corregido la Av. Bernardino Rivadavia, por lo general
ingreso numeración de los lugares que visito laboralmente en mis tareas de
agrimensor

Sos bien venido al grupo, no dejes de sumarte a nuestro foro y de hacer las
consultas que gustes
JOSM es un buen editor, en particular si queres agregar numeración

Slds
Beerforfree


2017-12-28 15:35 GMT-03:00 Jorge Aguirre :

> Buen día.
>
> Al estar ingresando direcciones (alturas) que aparecen en los edificios en
> el area de *Partido de Lanús* pude observar que éstos no coinciden con la
> interpolación que ha sido ingresada a la base de datos.  Resulta que la
> numeración de los pares y los impares se encuentra ingresada del lado
> contrario en las calles.  Incluso la secuencia de la numeración de menor a
> mayor está, aparentemente, invertida.
>
> Esto lo descubrí específicamente sobre la calle Doctor Roberto Paxtot ,
> entre las calles Alfredo Palacios y Jean Juares, pero al revisar el área
> adyacente, en general, parece que el error es bastante extenso.
>
> Me comuniqué con el autor (*hcastellaro*) quien me confirmó que los datos
> utilizados en una importación (de una supuesta buena fuente - *Dirección
> Provincial de Estadística*) tenía errores, sin embargo no se ofreció a
> corregirlos.  Debo suponer que aun no cuenta con los datos correctos.  La
> última edición se realizó en Dic/16.
> https://www.openstreetmap.org/changeset/44361343
>
> Desconozco cuál sea la metodología adoptada por ustedes para casos como
> éste y cómo se debe proceder. - Creo que en este caso específico conviene
> borrar lo ingresado y empezar de cero.  Lamentablemente, no cuento con la
> suficiente información para corregir este hallazgo, tan solo puedo ingresar
> como referencia los edificios con las alturas que sean perfectamente
> legibles en las fotografías.  Por esta razón, recurro a ustedes para lograr
> corregir esto con información correcta y actualizada.  Yo podría colaborar,
> en cierta medida, pero necesitaría acceso a una fuente confiable. Es
> preferible que no se incluyan las alturas - a tenerlas mal ingresadas.
>
> En un correo anterior intenté adjuntar una muestra de fotos
> geo-referenciadas de las alturas en el area descrita, pero parece que el
> archivo era muy grande y no pudo llegarles.
>
> Quedo a la espera de sus comentarios.
>
> Atentamente,
>
>
> Jorge Aguirre
> Geographer
> Kaart Group, LLC
> jo...@kaartgroup.com
> +(502) 4191 1999 
> www.kaartgroup.com
>
>
>
> *“Let's make our planet great again.”*
> - Emmanuel Macron
>   President of France
>
>
>
> ___
> Talk-ar mailing list
> Talk-ar@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ar
>
>
___
Talk-ar mailing list
Talk-ar@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-de] Chemnitzer Linuxtage 2018 - ist da jemand aktiv?

[Toni Erdmann]

Am 29.12.2017 um 00:50 schrieb lars lingner:

Hallo zusammen,

auf dem 34C3 wurde ich heute gefragt, warum von OSM bisher keine
Anmeldung für die Chemnitzer Linuxtage 2018 [1] kam. Die Frage konnte
ich nicht beantworten und ich muss gestehen, ich war auch noch nie dabei.

Es wäre laut OSM-Wiki [2] das 10. Jahr mit OSM-Beteiligung. Irgendwie
muss OSM auch einen positiven Eindruck hinterlassen haben, wenn man auf
eine fehlende Anmeldung hingewiesen wird.

Besteht denn Interesse einen Stand auf den CLT zu haben? Gibt es Hürden?
Wird Hilfe benötigt?

Eine Anmeldung ist noch bis 08.01.2018 möglich.



Ich war im März das erste Mal dabei und hatte den Eindruck, dass Jürgen 
und Andre das organisiert hatten. Aber mein Eindruck kann mich auch 
täuschen.


Gruß
ToniE

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

Re: [OSM-talk-fr] Visualiser historique changements dans une zone ?

[osm . sanspourriel]

Je crois que tu te trompes.

Quand tu vois


   Public transport features around Normandie

ça peut faire drôle mais le bbox comprend Paris.

Ça veut dire que la comparaison se fait simplement sur la bbox.
Par exemple mon renommage des communes fait presque la France entière 
alors qu'il n'y a qu'une demie-douzaine de communes de concernées.
J'aurais peut-être dû faire des changeset différents (comme le suggère 
Vincent).


Jean-Yvon

Le 29/12/2017 à 19:24, Shohreh - codecompl...@free.fr a écrit :

Bonjour,

J'imagine que c'est possible mais n'ai pas trouvé comment faire.

Via l'interface web d'OSM, j'aimerais visualiser l'historique de les
changements qui ont été apportés dans une zone donnée:

http://www.openstreetmap.org/history#map=17/48.83847/2.30799

Quand je clique sur History, l'interface semble montrer tous les changements
à OSM dans le monde, pas juste à la zone affichée. Me trompe-je ?

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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: [OSM-talk-fr] Visualiser historique changements dans une zone ?

[Vincent Privat]

non c'est bien ça, ça montre les changesets qui impactent la zone.
Le problème vient des gens qui font ce genre de changeset et qui polluent
donc l'historique:
http://www.openstreetmap.org/changeset/55004218

Le 29 décembre 2017 à 19:24, Shohreh  a écrit :

> Bonjour,
>
> J'imagine que c'est possible mais n'ai pas trouvé comment faire.
>
> Via l'interface web d'OSM, j'aimerais visualiser l'historique de les
> changements qui ont été apportés dans une zone donnée:
>
> http://www.openstreetmap.org/history#map=17/48.83847/2.30799
>
> Quand je clique sur History, l'interface semble montrer tous les
> changements
> à OSM dans le monde, pas juste à la zone affichée. Me trompe-je ?
>
> Merci.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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: [OSM-talk-fr] Visualiser historique changements dans une zone ?

[pepilepi...@ovh.fr]

  
  
Le 29/12/2017 à 19:24, Shohreh a
  écrit :


  Bonjour,

J'imagine que c'est possible mais n'ai pas trouvé comment faire.

Via l'interface web d'OSM, j'aimerais visualiser l'historique de les
changements qui ont été apportés dans une zone donnée:

http://www.openstreetmap.org/history#map=17/48.83847/2.30799

Quand je clique sur History, l'interface semble montrer tous les changements
à OSM dans le monde, pas juste à la zone affichée. Me trompe-je ?

Merci.

Bonsoir,
Essaie peut-être http://simon04.dev.openstreetmap.org/whodidit/
  ?


JP


  



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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




-- 
  

  
     
  Joyeux Noël et Bonne Année 2018

  

  

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

[Talk-de] Maxspeededitor: Wie speichern?

[markus schnalke]

Hoi,

heute habe ich den Maxspeededitor 
entdeckt. Der war mir hilfreich, um vergessene Strassen in grossen
30er-Zonen zu finden ... und hinzufuegen kann man die Tempolimits auch
... scheinbar, denn die Frage ist wie man dort speichert?

Ich klicke auf eine Strasse ohne Tempolimit (rot eingefaerbt), dann
waehle ich das korrekte Tempolimit aus. Aber ich sehe keine
Moeglichkeit, die Aenderung dann zu speichern. Da die gleiche Strasse
dann nicht mehr auswaehlbar ist, scheint doch irgendwas ``gespeichert''
zu sein. In der OSM wurde aber keine Aenderung durchgefuehrt. Meinen
OSM-Account wollten sie auch nicht nutzen.

Werden die Aenderungen moeglicherweise gesammelt in groesseren
Intervallen asynchron eingetragen?

Leider finde ich keinerlei Dokumentation zu diesem Maxspeededitor.

Waere super, wenn mir jemand weiterhelfen koennte.


meillo

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

[OSM-talk-fr] Visualiser historique changements dans une zone ?

[Shohreh]

Bonjour,

J'imagine que c'est possible mais n'ai pas trouvé comment faire.

Via l'interface web d'OSM, j'aimerais visualiser l'historique de les
changements qui ont été apportés dans une zone donnée:

http://www.openstreetmap.org/history#map=17/48.83847/2.30799

Quand je clique sur History, l'interface semble montrer tous les changements
à OSM dans le monde, pas juste à la zone affichée. Me trompe-je ?

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-it] Trinceroni

[demon.box]

liste DOT girarsi AT posteo DOT eu wrote
> Quanto al tunnel, guardando il wiki ci starebbe tunnel=culvert [0], 
> visto che è di fatto un passaggio coperto, insieme a layer=-1.

sul fatto di mettere tunnel=culvert anzichè tunnel=yes non sono proprio
convinto perchè ci sono dei tratti come questo 

 

dove si può letteralmente camminare sulla parete superiore in cemento (qui
si ci potrebbe stare tunnel=culvert) mentre in altri tratti come questo

 

si presenta chiaramente come una galleria scavata (almeno 1.5m sotto il
livello del terreno) e quindi secondo me sarebbe più appropriato tunnel=yes

inoltre queste gallerie hanno al loro termine delle bocche come queste

 
 

che non sono sicuramente fatte per entrare/uscire ma a me sembrano più
postazioni di osservazione e quindi ci metterei (secondo il wiki):

military=bunker
bunker_type=observation
disused=yes
start_date=1915
end_date=1945
historic=yes

che dite?
grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk] massgis:MANAGR_ABR=M173BS, massgis:DEED_ACRES=0.00000000 and other useless(?) tags

[Greg Troxel]

Mateusz Konieczny  writes:

> I encountered https://www.openstreetmap.org/way/29690455 that is
> obviously result of some unfinished import - somebody dumped random
> database fields into OSM such as
>
> massgis:DEED_ACRES=0.
> massgis:MANAGR_ABR=M173BS

It's actually a finished import from very long ago when norms were
different :-)

This is an issue only in Massachusetts.  I don't think you'll find them
in any other state (but if so please say where).

We locals are aware of this, and cleaning up the tags is on the
nice-to-do eventually list.  But it doesn't seem that important or
urgent compared to other mapping needs.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Importing Shell fuel stations

[Ian Caldwell]

It was the only house between two junctions on a road. It was in the
country.


Ian

On 29 December 2017 at 13:08, Mark Goodge  wrote:

>
>
> On 29/12/2017 11:41, Ian Caldwell wrote:
>
>>
>>
>>
>> On 29 December 2017 at 10:47, Mark Goodge  m...@good-stuff.co.uk>> wrote:
>>
>> since a filling station isn't going to be large enough to have a
>> single-user postcode
>>
>>
>> Not necessarily I used to own a three bedroom house that had its own
>> postcode.
>>
>
> That sounds a little implausible. Are you sure it wasn't just the only
> *house* within that postcode? Or was it, possibly, the only remaining
> property with that postcode after others have been reassigned (or
> demolished)?
>
> (It's relatively easy to check, if you give us the postcode, even if it's
> now a defunct one).
>
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] modification au 1er janvier

[Philippe Verdy]

Clairement il n'y a pas de commune déléguée pour "Dinan-Ville" (ce qui
semble être la désignation de cette partie si on en juge par le titre donné
à une personne) qui serait donc simplement une "ancienne" commune dont ne
resterait que le découpage administratif des quartiers. Si on la garde ce
n'est plus un admin_level 8 mais de niveau 10 comme la nouvelle commune
déléguée. On peut distinguer les statuts de Dinan-Ville et de Lahon avec
admin_type:FR=* mais quelle valeur donner pour Dinan-Ville autre que
"ancienne commune" contrairement à Lahon qui serrait "commune déléguée".
Puisqu'il y a une commune déléguée, les INSEE sont conservés et la
toponymie aussi pour Lahon, la toponymie de Dinan en revanche doit être
changée et ce serait "Dinan-Ville" selon l'arrêté.


Le 29 décembre 2017 à 12:17,  a écrit :

> Alors que toutes les créations au JO sont similaires (création d'une
> commune, disparition des autres), pour Dinan (une des communes signalées
> par Stéphane) je vois qu'il y a création d'une commune nouvelle (Dinan)
> mais aussi d'une commune déléguée Léhon.
>
> Par contre l'ancienne commune de Dinan cesse d'être.
>
> Je ne sais si c'est du fait de ces originalités ou du fait de la décision
> préfectorale tardive (30/09/2017).
>
> Question subsidiaire : si le texte n'est pas publié au JO avant le 1er,
> quel sera le statut des communes ?
> Jean-Yvon
>
> Le 29/12/2017 à 07:55, Stéphane Péneau - stephane.pen...@wanadoo.fr a
> écrit :
>
> Il y a un peu plus de communes nouvelles ici :
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_
> cr%C3%A9%C3%A9es_en_2018
>
>
>
> ___
> 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-it] cimiteri in Italia

[Elena ``of Valhalla'']

On 2017-12-29 at 10:49:10 +0100, Cascafico Giovanni wrote:
> Mi sembra che questi tag complichino le cose...
> 
> Che facciamo di un cimitero antico  non adiacente ad una chiesa?

credo che l'antico di Martin fosse più una questione di stile che non di
età: un cimitero monumentale dell'ottocento ormai potrebbe anche
considerarsi antico, ma è nello stile "moderno" post-napoleonico del
cemetery.

A quanto ho capito, cemetery è il cimitero nuovo stile (che qui da noi
ha imposto Napoleone) fuori dal nucleo abitato con tutte le tombe messe
ben in ordine con confini chiaramente segnati, mentre graveyard è quello
vecchio stile che era tipicamente dentro al nucleo abitato (vicino alla
chiesa, appunto), in cui capita che le tombe rimangano sovrapposte le
une alle altre e cose del genere.

-- 
Elena ``of Valhalla''

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

Re: [OSM-talk] GPS Watch

[Mike Thompson]

Russ,

Thanks!  So many options, even from this one vendor.

Mike

On Thu, Dec 28, 2017 at 10:03 PM, Russ Nelson  wrote:

> Craig Wallace writes:
>  > Or another option is the Garmin Foretrex 601. It is much bulkier and
>  > heavier than most watches, maybe a bit too big to wear on your wrist.
>  > But OK if you attach it to a rucksack strap. It has much better battery
>  > life - it claims 48 hours. It uses AAA batteries, so you can carry
>  > spares if necessary. And probably more accurate - should be a bigger
>  > antenna, and it can use GPS, GLONASS and Galileo.
>
> Forerunner is designed for runners. Foretrex is a GPS receiver. Get
> the Foretrex.
>
> --
> --my blog is athttp://blog.russnelson.com
> Crynwr supports open source software
> 521 Pleasant Valley Rd. | +1 315-600-8815
> Potsdam, NY 13676-3213  | Sheepdog
>
> ___
> 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-fr] Contours des IRIS

[Philippe Verdy]

Le problème des contours fournis en open data par l'IGN c'est qu'il n'y a
pas de conflation avec les frontières administratives ou électorales: leur
précision est somme toute assez sommaire (suffisante pour créer une carte
statistique, mais pas pour les corréler correctement avec les données
géographiques, administratives ou électorales existantes et cela pose des
problèmes justement pour faire des rapprochements statistiques. Ces IRIS
sont des polygones nus détachés de tout le reste.

Ma question essentielle portait sur le tag à utiliser si on veut commencer
à en importer au moins dans quelques communes test avant de généraliser et
faire un projet pour les finaliser. Je ne vois pas en quoi cela ne serait
pas approprié dans OSM alors que c'est beaucoup plus important que la
localisation précise d'un lampadaire, et très utile à plein de besoins
économiques, sociaux, environnementaux, et qu'on a de nombreuses données
libres attachées au niveau des IRIS.

Ce n'est pas un gros projet et cela ne représentera pas énormément de
données en comparaison des adresses, des bâtiments, des rues/routes. Et
c'est certainement plus utile que la forme des toits, la couleur des murs
ou les espèces des arbres: les IRIS visent d'abord à cibler la population
de façon plus fine que les communes (et c'est encore plus important
maintenant que les communes fusionnent de plus en plus: les IRIS
représentent nettement mieux les populations là où elle vit, et les
services dont elles peuvent disposer près de chez elles (exemple : analyse
de la proximité des lignes de transport, plans de déplacements urbains et
voies de communications, commerce de proximité, services sociaux, sécurité
et police, évaluation fine des risques environnementaux ou industriels,
bassins d'emploi, services de santé, etc.)...

Le 29 décembre 2017 à 14:56, Cyrille37 OSM  a
écrit :

> Salut
>
> Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur qu'il
> y a déjà énormément de mise à jour à suivre pour les éléments existants.
> Donc je pense que les IRIS sont très bien hors OSM et qu'il est facile pour
> qui sait faire des analyses, de les associés aux données OSM avec les
> outils adéquates.
> C/.
>
>
> Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
>
> De nombreuses cartes statistiques pourraient utiliser les délimitations
> infracommunales (les IRIS).
> Elles sont libres (licence LO/OL).
> Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces
> contours pour les frontières communales, et les quartiers administratifs,
> et que ces IRIS sont aussi à la base de la délimitation du fractionnement
> cantonal qui s'appuie sur les statistiques fines de population calculées
> par IRIS).
> Ce ne serait pas des frontières adminsitratives (boundary=administrative,
> mais statistiques (boundary=statistic). Et cela permettrait de recoller
> aussi avec le fractionnement cantonal des grandes communes.
>
> On a ces données sur http://professionnels.ign.fr/contoursiris
> (certes avec un tracé approximatif le long des rues, mais un tel import,
> ne concernant que les communes divisées en IRIS, pourrait dans un premier
> temps se faire sur des chemins séparés pour permettre ensuite une
> conflation avec les frontières communales ou de quartiers administratifs ou
> arrondissements municipaux).
>
> Ces IRIS jouent un rôle important en terme de planification des projets
> publics et tout aussi important pour l'activité commerciale (zones de
> chalandises, études d'impact ou d'opportunité, etc) grace à la finesse des
> statistiques collectées par l'INSEE à ce niveau.
>
> Peut-on créer un projet contenant une liste des communes subdivisées en
> IRIS avec un indicateur d'avancement (nombre d'IRIS à cartographier),
> éventuellement sur plusieurs sous-pages par département ou région ?
>
> Que pensez vous du tag "boundary=statistic" (avec éventuellement un tag
> additionnel "admin_type:FR=iris" ou plutôt "border_type=FR:iris" puisque ce
> n'est pas strictement adminsitratif et qu'il n'y a pas de collectivité ou
> de personne morale associée à cette entité de découpage et d'aménagement
> territorial, très utile en France pour pouvoir représenter des tas de
> statistiques comme le propose déjà le "http://map.datafrance.info/; de
> l'INSEE sur un fond de carte OSM/CartoDB)?
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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

Re: [OSM-talk] shop windows on differnt streets

[Oleksiy Muzalyev]

If you can make a quality photo of a shop yourself, then you can add it 
to the respective category at Wikimedia. Here is an example of such a 
category for a retailer:

https://commons.wikimedia.org/wiki/ALDI

Then you can add the tag to this shop image=*. A picture is worth a 
thousand words.


Please, note that normally it is not allowed to add photos to Wikimedia 
which were not made by oneself  due to licensing issues.


Here is some info on the OSM image=* tag : 
https://wiki.openstreetmap.org/wiki/Key:image


brgds
Oleksiy
OSM: Alex-7



On 27.12.17 19:36, Catonano wrote:

I hope this is the right place to ask about tagging

There s this shop that has shop windows on 2 streets
https://imgur.com/a/icpwJ

Some of its shop windows have street numbers. as shown here
https://imgur.com/a/ny08t

This is  a quite common case, as you can see here
https://photos.app.goo.gl/Vr2vKuqr1S5hjf772

Some have their shop windows separated by building entrances or a 
different shop windows


How do I map these ?

My idea is that every shop window should be its own point with address 
info and then a relation should group them and be tagged with common 
data, such as the shop name, the web site, the phone number, the 
operator, whatever


Does anyone here know of any example of a similar situation ?

Thanks


___
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-fr] Contours des IRIS

[Cyrille37 OSM]

Salut

Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur 
qu'il y a déjà énormément de mise à jour à suivre pour les éléments 
existants. Donc je pense que les IRIS sont très bien hors OSM et qu'il 
est facile pour qui sait faire des analyses, de les associés aux données 
OSM avec les outils adéquates.


C/.

Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
De nombreuses cartes statistiques pourraient utiliser les 
délimitations infracommunales (les IRIS).

Elles sont libres (licence LO/OL).
Peut-on envisager de les importer (sachant qu'on a déjà une partie de 
ces contours pour les frontières communales, et les quartiers 
administratifs, et que ces IRIS sont aussi à la base de la 
délimitation du fractionnement cantonal qui s'appuie sur les 
statistiques fines de population calculées par IRIS).
Ce ne serait pas des frontières adminsitratives 
(boundary=administrative, mais statistiques (boundary=statistic). Et 
cela permettrait de recoller aussi avec le fractionnement cantonal des 
grandes communes.


On a ces données sur http://professionnels.ign.fr/contoursiris
(certes avec un tracé approximatif le long des rues, mais un tel 
import, ne concernant que les communes divisées en IRIS, pourrait dans 
un premier temps se faire sur des chemins séparés pour permettre 
ensuite une conflation avec les frontières communales ou de quartiers 
administratifs ou arrondissements municipaux).


Ces IRIS jouent un rôle important en terme de planification des 
projets publics et tout aussi important pour l'activité commerciale 
(zones de chalandises, études d'impact ou d'opportunité, etc) grace à 
la finesse des statistiques collectées par l'INSEE à ce niveau.


Peut-on créer un projet contenant une liste des communes subdivisées 
en IRIS avec un indicateur d'avancement (nombre d'IRIS à 
cartographier), éventuellement sur plusieurs sous-pages par 
département ou région ?


Que pensez vous du tag "boundary=statistic" (avec éventuellement un 
tag additionnel "admin_type:FR=iris" ou plutôt "border_type=FR:iris" 
puisque ce n'est pas strictement adminsitratif et qu'il n'y a pas de 
collectivité ou de personne morale associée à cette entité de 
découpage et d'aménagement territorial, très utile en France pour 
pouvoir représenter des tas de statistiques comme le propose déjà le 
"http://map.datafrance.info/; de l'INSEE sur un fond de carte 
OSM/CartoDB)?




___
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: [OSM-talk] shop windows on differnt streets

[Dave F]

Hi
I think you're seriously over complicating this.
Just look up the address on their website & use that.
Multiple house numbers: '107-109'

There's a separate tagging forum: 
https://lists.openstreetmap.org/listinfo/tagging


DaveF

On 27/12/2017 17:36, Catonano wrote:

I hope this is the right place to ask about tagging

There s this shop that has shop windows on 2 streets
https://imgur.com/a/icpwJ

Some of its shop windows have street numbers. as shown here
https://imgur.com/a/ny08t

This is  a quite common case, as you can see here
https://photos.app.goo.gl/Vr2vKuqr1S5hjf772

Some have their shop windows separated by building entrances or a 
different shop windows


How do I map these ?

My idea is that every shop window should be its own point with address 
info and then a relation should group them and be tagged with common 
data, such as the shop name, the web site, the phone number, the 
operator, whatever


Does anyone here know of any example of a similar situation ?

Thanks


___
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-GB] Non-free sources [was: Re: Importing Shell fuel stations]

[David Woolley]

On 29/12/17 13:05, Mark Goodge wrote:
We draw the line at using a source which is subject to database right, 
and where using the content would be an infringement of that right.


We also don't allow material used in breach of contract, even if only a 
click wrap contract.  Google Street View falls into that category, as 
well as possibly being a database (facts organised by geographical 
location).   Most web sites attempt to create contracts limiting the use 
of the information they contain.


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

Re: [Talk-GB] Importing Shell fuel stations

[Mark Goodge]

On 29/12/2017 11:41, Ian Caldwell wrote:




On 29 December 2017 at 10:47, Mark Goodge > wrote:


since a filling station isn't going to be large enough to have a
single-user postcode


Not necessarily I used to own a three bedroom house that had its own 
postcode.


That sounds a little implausible. Are you sure it wasn't just the only 
*house* within that postcode? Or was it, possibly, the only remaining 
property with that postcode after others have been reassigned (or 
demolished)?


(It's relatively easy to check, if you give us the postcode, even if 
it's now a defunct one).


Mark

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

Re: [Talk-GB] Non-free sources [was: Re: Importing Shell fuel stations]

[Mark Goodge]

On 29/12/2017 11:14, Andy Mabbett wrote:

On 29 December 2017 at 08:30, Adam Snape  wrote:


Speaking generally, I don't think it's good practice to be using
non-free resources like this to research information which is
not clear from open data, even if we don't use the information
directly.


Are you happy for people to enter into OSM the name of a store, read
from the store's shop-front signage?

What if that signage is an artistic design, meriting copyright?

What if it is written in a proprietary, copyrighted font?


Names aren't subject to copyright. They may be protected by trademarks, 
but mapping them is not an infringement of a trademark.  So, provided we 
didn't discover the name from a source which is itself protected by 
database right (eg, a proprietary directory such as Yellow Pages), then 
there's nothing stopping us from using a name. Reading it directly from 
the shopfront would always be OK. And we're not reproducing the font or 
the logo, so that's immaterial.



What about from a non-free photograph, found online? Or in a book,
magazine or newspaper?


Those are fine. We are not reproducing any of the content, we are merely 
ascertaining facts.



Were exactly do we draw the line? Why there?


We draw the line at using a source which is subject to database right, 
and where using the content would be an infringement of that right. 
Because facts are not subject to copyright, but a collection of facts 
can be subject to database right. And it's the database right which, in 
the context of OSM, is the key issue.


Mark


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

[OSM-talk-fr] Contours des IRIS

[Philippe Verdy]

De nombreuses cartes statistiques pourraient utiliser les délimitations
infracommunales (les IRIS).
Elles sont libres (licence LO/OL).
Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces
contours pour les frontières communales, et les quartiers administratifs,
et que ces IRIS sont aussi à la base de la délimitation du fractionnement
cantonal qui s'appuie sur les statistiques fines de population calculées
par IRIS).
Ce ne serait pas des frontières adminsitratives (boundary=administrative,
mais statistiques (boundary=statistic). Et cela permettrait de recoller
aussi avec le fractionnement cantonal des grandes communes.

On a ces données sur http://professionnels.ign.fr/contoursiris
(certes avec un tracé approximatif le long des rues, mais un tel import, ne
concernant que les communes divisées en IRIS, pourrait dans un premier
temps se faire sur des chemins séparés pour permettre ensuite une
conflation avec les frontières communales ou de quartiers administratifs ou
arrondissements municipaux).

Ces IRIS jouent un rôle important en terme de planification des projets
publics et tout aussi important pour l'activité commerciale (zones de
chalandises, études d'impact ou d'opportunité, etc) grace à la finesse des
statistiques collectées par l'INSEE à ce niveau.

Peut-on créer un projet contenant une liste des communes subdivisées en
IRIS avec un indicateur d'avancement (nombre d'IRIS à cartographier),
éventuellement sur plusieurs sous-pages par département ou région ?

Que pensez vous du tag "boundary=statistic" (avec éventuellement un tag
additionnel "admin_type:FR=iris" ou plutôt "border_type=FR:iris" puisque ce
n'est pas strictement adminsitratif et qu'il n'y a pas de collectivité ou
de personne morale associée à cette entité de découpage et d'aménagement
territorial, très utile en France pour pouvoir représenter des tas de
statistiques comme le propose déjà le "http://map.datafrance.info/; de
l'INSEE sur un fond de carte OSM/CartoDB)?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Importing Shell fuel stations

[Ian Caldwell]

On 29 December 2017 at 10:47, Mark Goodge  wrote:

> since a filling station isn't going to be large enough to have a
> single-user postcode
>
>
Not necessarily I used to own a three bedroom house that had its own
postcode.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] modification au 1er janvier

[osm . sanspourriel]

Alors que toutes les créations au JO sont similaires (création d'une 
commune, disparition des autres), pour Dinan (une des communes signalées 
par Stéphane) je vois qu'il y a création d'une commune nouvelle (Dinan) 
mais aussi d'une commune déléguée Léhon.


Par contre l'ancienne commune de Dinan cesse d'être.

Je ne sais si c'est du fait de ces originalités ou du fait de la 
décision préfectorale tardive (30/09/2017).


Question subsidiaire : si le texte n'est pas publié au JO avant le 1er, 
quel sera le statut des communes ?


Jean-Yvon

Le 29/12/2017 à 07:55, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :

Il y a un peu plus de communes nouvelles ici :
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2018


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

Re: [OSM-talk-fr] Hiérarchie des relations d’itinéraire cyclistes

[marc marc]

Le 29. 12. 17 à 10:10, Axelos a écrit :
> Coucou,
> 
> Le 28/12/2017 à 00:37, marc marc a écrit :
 Je n'ai pas compris pourquoi dans une relation enfant "pas de from=* et
 to=*"
 Quel problème aurait une relation Toul-Pompey avec from=Toul to=Pompey ?
>>> En effet c'est mal formulé, certaines boucles touristiques ont un départ
>>> et arrivé au même endroit. Là ce n'est pas le cas.
>> de même les relations enfant de la boucle ne sont chacun prise
>> individuelement pas une boucle, il faut donc supprimer le rountrip
>> lorsqu'il y a un from et to différent.
> 
> 
> J'ai un peu répondu à côté de la plaque précédemment …
> 
> Non les 4 relations enfants qui constituent la Boucle de la Moselle ne
> sont pas des étapes, mais ont unique but d’être intégrés dans la
> relation parente Boucle de la Moselle et les Véloroutes 50 et 52.
> 
> Si usage des from= et to= , ils doivent donc rester les mêmes sur
> chacune de ces 4 relations enfants ainsi que la relation parente Boucle
> de la Moselle pour que le logiciel qui réutilise les données ne dédouble
> pas l'information,

ce n'est pas possible :) exemple avec la zone 3 Toul - Richardménil
https://www.openstreetmap.org/relation/7730465
la relation enfant ne saurait pas avoir les même tag from-to que ses 
parents vu qu'elle a plusieurs parents :) Idem pour le nom.
Tu pourrais changer ta règle en disant de prendre la relation la + 
locale, mais cela ne fait que reporter le problème en cas de segment 
commun entre 2 itinéraires de même niveau.
c'est pourquoi je pense qu'il faut considérer ce segment commun comme un 
étape et garder les tag en cohérence (from-to qui décrive l'étape).
Après si cela pose un problème de rendu, peut-être que l'absence de tag 
name pourrait aider à la décision.
il faudrait voir quels sont les règles qu'ils utilisent actuellement 
pour idéalement éviter d'avoir à faire une règle supplémentaire.
ceci dit je suis pas persuadé que cela soie grave de voir que la boucle 
de la Moselle a 4 "pseudo-étapes" avec sûrement des implications sur le 
terrain (ne fusse que la multiplicité des balisages sur les segments 
communs).

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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[marc marc]

Le 28. 12. 17 à 15:51, Nicolas Frery a écrit :
> Le 28/12/2017 à 00:25, marc marc a écrit :
>> Le 27. 12. 17 à 20:02, Nicolas Frery a écrit :
>>> Il faudrait créer une nouvelle valeur pour différencier les voies
>>> cyclables sur trottoir d'une piste cyclable en bonne et due forme.
>> de cas cas sur la page wiki parles-tu ?
>> tous les cas ont l'air différentié
> Les cas S3 et S4 http://wiki.openstreetmap.org/wiki/Bicycle
> 1) voie cyclable sur trottoir bien délimitée (ne regardons pas les
> largeurs honteuses des différents cheminements)
> https://framapic.org/2X8j458fJxkC/NEMJqGVzxxGT.PNG

pas d'obstacle entre la rue et le trottoir (= un piéton est capable
de traverser où il veux)
donc un seul chemin route+piéton+vélo dans osm
piéton et vélo ont un espace supposé séparé pour les 2
c'est le cas s3 (on pourrait imaginer un segregated=bad)

> 2) voie cyclable sur trottoir, aucune délimitation
> https://framapic.org/hYyk6SWFU5vY/duaHrKz1I5gv.PNG

si tu parles du trottoir en arrière plan,
pas d'obstacle entre la rue et le trottoir (= un piéton
est capable de traverser où il veux)
donc toujours un seul chemin route+piéton+vélo dans osm.

> la ville n'a pas marqué correctement la voie cyclable
> Il y a bien un marquage au sol, des carrés vert de 10cm. Suffisamment
> pour affirmer sa délimitation avec le cheminement piéton.

J'ignore ce que la ville aurait voulu donné comme sens (peu importe on 
ne tag pas l'intention)
Je ne vois pas non plus les fameux carrés vert dont tu parles.
Si ces marques sont clairs, on est en à nouveau en s3 segregated=yes

> 3) piste cyclable et trottoir séparé par une marche de quelques centimètres
> https://framapic.org/97lY57zM6TEE/iLKmEw0MB4KY.PNG
> le scénario S4 convient tout à fait

non, toujours pas d'obstacle entre le trottoir et la route.
S4 casserait le routing, on est toujours en s3
D'ailleurs sans marquage au sol, j'ignore si c'est une piste cyclable 
bidirectionnelle avec le piéton qui doit frôler le lampadaire (sympa 
pour les fauteuils roulants) ou si c'est une bande vélo et une bande 
piéton avec un "truc" à côté.

D'ailleurs je ne vois aucune différence entre ta photo 1 et 3 hormis
la largeur des bandes.
Dans les 2 cas, si tu passes à côté d'un piéton a 25km/h,
il te faut une pharmacie lorsque le piéton voudra croiser la bande
pour rentrer chez lui. Seul le largeur de la bande te permet
de limiter le risque.

Pour la différence s3 <> s4, je t'invite à regarder la photo T1 qui 
illustre la séparation qui implique que niveau routing, je ne peux pas 
prendre une rue transversale m'importe où.

J'ai trouvé une page intéressante :
http://wiki.openstreetmap.org/wiki/Key:class:bicycle
La partie que je trouve la + intéressante c'est la fin où des 
programmeurs expliquent pourquoi elle n'est pas utile (en plus d'être 
totalement subjective (le cas  class:bicycle:roadcycling=-2 mériterait 
pour moi un +1 vu que la large séparation t'empêche de subir une 
portière ou un piéton, il n'y a qu'aux carrefour où il faut ralentir, 
comme dans tout les carrefours)

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

Re: [Talk-GB] Importing Shell fuel stations

[Mark Goodge]

On 28/12/2017 22:33, Warin wrote:


Could the post code be derived from surrounding features?
I don't know how detailed the post codes there are .. but if features in 
OSM surrounding it were of the same post code (and correct) then they 
could be used to derive the post code?


It will almost certainly share a postcode with at least one neighbouring 
property, yes. A filling station is not going to receive enough post to 
justify a "large user" postcode. So if it's surrounded by properties 
that all have the same postcode, then that's definite enough. But if one 
neighbour has one postcode, and a different neighbour has a different 
one, then we can't be certain which is correct for this property... :-)


Mark

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

Re: [Talk-lv] Ādažu poligons

[Rihards]

On 2017.12.28. 22:00, Kārlis Šteinbergs wrote:
> Sveicināti!
> 
> Skatos, ka OSM kartē nav paplašināta Ādažu poligona teritorija.
> 
> Vai ir kādas idejas kā varētu labot šo kļūdu (esmu kādu brīdi izkriti no
> aprites :) )?

oho, iespaidīgs palielinājums.

par ko tieši jautājums - kā atrast labu un legālu datu avotu vai arī kā
tehniski iezīmēt jaunās robežas ?

pirmo īsti nezinu; otrais - tur ir relation, bet jāuzmanās, jo sakrīt
arī ar aizsargājamajām teritorijām. tās laikam nevajag mainīt.

> http://www.delfi.lv/news/national/politics/adazu-poligona-teritorija-sogad-paplasinata-par-5259-hektariem.d?id=49594035
> 
> Dabā esmu pārliecinājies, ka dienvid-austrumu stūrī jaunajā teritorijā
> jau dabā jau ir poligona apzīmējumi.
-- 
 Rihards

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

Re: [Talk-GB] Importing Shell fuel stations

[Mark Goodge]

On 29/12/2017 08:30, Adam Snape wrote:

Hi,

I don't think we would delete a postcode found in other Open Data just 
on the basis of it not being in Codepoint Open; the error could lie in 
Codepoint Open itself. I suggest that a FIXME would be appropriate where 
two sources appear to contradict each other.


There are two open data sources of postcodes: Codepoint Open and the ONS 
Postcode Database. Ultimately, both of those are populated from Royal 
Mail data, since it's RM that assigns postcodes. So if CPO and ONSPD 
agree that a postcode is deleted (and I'm not aware of any instance in 
which they've disagreed), that's canonical.


I think a FIXME is probably a good solution here; hopefully there will 
be somebody on the ground who can verify the correct postcode simply by 
comparison with known postcodes for neighbouring properties (since a 
filling station isn't going to be large enough to have a single-user 
postcode).


Mark

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

Re: [OSM-talk-fr] Problème de téléchargement de données avec JOSM

[marc marc]

Bonjour,

Le 29. 12. 17 à 11:16, Vincent Bergeot a écrit :
> Le 29/12/2017 à 10:56, Gaël Simon a écrit :
>> Bonjour, cela fonctionne chez moi
> 
> merci,
> ce qui me surprend c'est que l'overpass fonctionne !!! donc à priori ce 
> n'est pas un souci de connexion internet !
> 
> est-ce que vous utilisez https://api/openstreetmap.org/api comme serveur 
> par défaut ?

J'utilise le serveur api par défaut.
Une recherche de lieu fonctionne.
Le téléchargement d'une bbox aussi.

Cela ne résout pas entièrement ton problème mais tu peux utiliser 
overpass pour télécharger la bbox
Cela soulage le serveur d'api et permet des bbox + grande.
Seul défaut un lag de 2 min et la non compatibilité avec le plugin revert.

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

Re: [OSM-talk] Standard map style contributions

[Christoph Hormann]

On Friday 29 December 2017, Andy Townsend wrote:
> [...]  As described in
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTO
>GRAPHY.md , OSM Carto has somewhat conflicting goals - both as "an
> important feedback mechanism for mappers" and as an "exemplar
> stylesheet".

Note the above document was originally written as the first part of a 
longer document that ends with more specific guidelines that were meant 
specifically to help contributors to recognize what kind of changes are 
desirable and which are not.  The maintainers could not agree on more 
specific design principles though which ultimately left this in an 
incomplete state that can be used to justify either accepting or 
rejecting a very wide range of changes.

https://github.com/gravitystorm/openstreetmap-carto/pull/2462

> With the last two issues it's difficult to know what to suggest -
> there has to be an overall style "direction" otherwise you just end
> up with something that is a bit of a mess.  Likewise there have to be
> some standards, but sometimes I suspect that if the maintainers
> actually want to see a fix to a particular problem that they'll need
> help potential contributors a bit more.

Actually if there is a need of a shared, overall design direction has 
been a subject of quite a bit of debate over the last 1-2 years - see 
for example here:

https://github.com/gravitystorm/openstreetmap-carto/issues/2270

While i agree with you that from my perspective a style direction or 
design paradigm is needed for successful development i try to be open 
to the possibility that it is not.  How to attract contributors in such 
a framework is not something i can provide a competent opinion on 
though.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] Problème de téléchargement de données avec JOSM

[Vincent Bergeot]

Le 29/12/2017 à 10:56, Gaël Simon a écrit :

Bonjour, cela fonctionne chez moi


merci,
ce qui me surprend c'est que l'overpass fonctionne !!! donc à priori ce 
n'est pas un souci de connexion internet !


est-ce que vous utilisez https://api/openstreetmap.org/api comme serveur 
par défaut ?


merci







Gaël

Le 29 déc. 2017 à 09:40, Vincent Bergeot > a écrit :


Bonjour,

depuis ce matin je n'arrive plus à télécharger des données dans JOSM.




Dans le téléchargement de données, si je fais une recherche de lieu 
alors j'ai également un souci





c'est de mon coté que cela ne marche pas ?

Bonne journée

--
Vincent Bergeot
___
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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Problème de téléchargement de données avec JOSM

[Gaël Simon]

Bonjour, cela fonctionne chez moi

Gaël

Le 29 déc. 2017 à 09:40, Vincent Bergeot  a écrit :

Bonjour,

depuis ce matin je n'arrive plus à télécharger des données dans JOSM.




Dans le téléchargement de données, si je fais une recherche de lieu alors j'ai 
également un souci 



c'est de mon coté que cela ne marche pas ?

Bonne journée
-- 
Vincent Bergeot
___
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-it] cimiteri in Italia

[Cascafico Giovanni]

Mi sembra che questi tag complichino le cose...

Che facciamo di un cimitero antico  non adiacente ad una chiesa?

Dalla foto in testata della wiki graveyard [1] perché non usare
semplicemente landuse=cemetery ?

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgrave_yard

Il 28/dic/2017 20:29, "Martin Koppenhoefer"  ha
scritto:

>
>
> sent from a phone
>
> > On 28. Dec 2017, at 12:08, Volker Schmidt  wrote:
> >
> >
> > 2)
> > Pensavo che landuse=cemetery e amenity=grave_yard sono alternative.
> Trovo parecchi cimiteri con entrambi i tag.
>
>
> amenity =graveyard lo vedo per i cimiteri “antichi”, cioè annessi ad una
> chiesa, mentre i cimiteri normali non fanno parte di una chiesa (hanno una
> cappella per il rito di sepoltura, ma non sono chiese normali). Anche se
> guardando il pelo, dovrebbe forse essere churchyard
>
>
> 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: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 29.12.2017 o 03:41, Andy Townsend pisze:

Speaking entirely personally, the main issue is just selfishness/laziness.


I wouldn't name it "laziness" or "selfishness", just lack of motivation 
and I understand why - you have enough motivation to develop your own 
fork, so it seems to me that you have just different needs (but you 
still hint us how do you solve different problems, which is helping).


This is also a kind of problem which is hard to solve, because it's not 
clear to me what makes people do anything more than just opening a ticket.


In case it helps anyone who does want to contribute but doesn't quite 
know where to start I've added a diary entry 
https://www.openstreetmap.org/user/SomeoneElse/diary/43041 that 
explains what I needed to do to submit 
https://github.com/gravitystorm/openstreetmap-carto/pull/2966 .


Thanks a lot for sharing your experience! I have added this link to the 
OSM Carto Wiki page.


I'd also not assume that everyone is familar with CSS.  In addition, 
the somewhat arcane way that some of the selections for layers are 
done in project.mml is, shall we say, not always that easy to follow.


Of course, but it doesn't sound to me as a major obstacle. I'm not even 
a coder in any language, all I can do is looking for analogies (with 
both CSS and SQL parts), testing in Kosmtik and asking if I don't 
understand something.


There are many "low-hanging fruits", which don't need any special 
skills, just playing with a code and communicating. There is also a 
demand for icons for different things and we look for people who can 
just use Inkscape, which means no coding at all.


Another reason why I've not added more pull requests is that in some 
cases I don't think that they'd be accepted.


Another reason is I suspect the "jumping through hoops" needed to get 
something accepted. 



With the last two issues it's difficult to know what to suggest


Yes, it's hard to find a solution for such general issues. I still hope 
we could recognize some other problems, which are more "fixable".


Anyway, I hope the above helps (and please understand that it's not 
meant as a criticism either of the style or the maintainers - it's 
just trying to provide answers to the questions that were asked).


Thanks, Andy - that's exactly the kind of the input I expected: personal 
and detailed. I wait to hear more such real stories, even if they ended 
up with not even a single line of code.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Talk-it] Trinceroni

[Cascafico Giovanni]

Se c'è una porta, come mi par di vedere da alcune foto, direi
barrier=sally_port e relativo access,  altrimenti sezionerei la way e
toglierei il covered dalla parte scoperta.

Il 27/dic/2017 19:16, "demon.box"  ha scritto:

> cascafico wrote
> > military=trench
> > covered=yes
>
> ciao, ok, questo sulla way e sul nodo in corrispondenza della bocca di
> entrata e di uscita non metto nulla?
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> 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: [OSM-talk-fr] Hiérarchie des relations d’itinéraire cyclistes

[Axelos]

Coucou,

Le 28/12/2017 à 00:37, marc marc a écrit :
>>> Je n'ai pas compris pourquoi dans une relation enfant "pas de from=* et
>>> to=*"
>>> Quel problème aurait une relation Toul-Pompey avec from=Toul to=Pompey ?
>> En effet c'est mal formulé, certaines boucles touristiques ont un départ
>> et arrivé au même endroit. Là ce n'est pas le cas.
> de même les relations enfant de la boucle ne sont chacun prise 
> individuelement pas une boucle, il faut donc supprimer le rountrip 
> lorsqu'il y a un from et to différent.


J'ai un peu répondu à côté de la plaque précédemment …

Non les 4 relations enfants qui constituent la Boucle de la Moselle ne
sont pas des étapes, mais ont unique but d’être intégrés dans la
relation parente Boucle de la Moselle et les Véloroutes 50 et 52.

Si usage des from= et to= , ils doivent donc rester les mêmes sur
chacune de ces 4 relations enfants ainsi que la relation parente Boucle
de la Moselle pour que le logiciel qui réutilise les données ne dédouble
pas l'information, donc restitue une unique relation Boucle de la
Moselle comprenant les enfants au lieu de 5.

Concernant l'usage de roundtrip= sur les enfants, j’avoue que j'ai pas
creusé le sujet, je suis juste partie dans la logique de ce que j'ai
expliqué ci-dessus.

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

[OSM-talk-fr] Problème de téléchargement de données avec JOSM

[Vincent Bergeot]

Bonjour,

depuis ce matin je n'arrive plus à télécharger des données dans JOSM.


Dans le téléchargement de données, si je fais une recherche de lieu 
alors j'ai également un souci



c'est de mon coté que cela ne marche pas ?

Bonne journée

--
Vincent Bergeot

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

Re: [Talk-de] Chemnitzer Linuxtage 2018 - ist da jemand aktiv?

[Joerg Fischer]

lars lingner wrote:

> Besteht denn Interesse einen Stand auf den CLT zu haben? Gibt es Hürden?

Ursache dürfte sein, dass Malenki, der das all die Jahre federführend
übernommen hat, letztes Jahr beim Wandern und mappen einen tödlichen Unfall
hatte...  http://wiki.openstreetmap.org/wiki/User:Malenki

Ich war zwei oder drei Mal als Standbetreuer mit dabei, andere Jahre hatte
er Unterstützung von anderen Leuten.  Komplett übernehmen nöchte ich das
nicht, weil ich in letzter Zeit aus verschiedenen Gründen bei OSM nur
noch wenig aktiv war.

VG Jörg

-- 
There are only 10 types of people in the world:
Those who understand binary, and those who don't...


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

Re: [Talk-GB] Importing Shell fuel stations

[Adam Snape]

Hi,

I don't think we would delete a postcode found in other Open Data just on
the basis of it not being in Codepoint Open; the error could lie in
Codepoint Open itself. I suggest that a FIXME would be appropriate where
two sources appear to contradict each other.

Of course in this case we know the correct answer (assuming it is accurate)
but that is only through the PAF. Speaking generally, I don't think it's
good practice to be using non-free resources like this to research
information which is not clear from open data, even if we don't use the
information directly. The problems are twofold, namely that such an
approach is using a unusable sources to validate open data and there is a
risk that mistakes or Easter eggs on the source could lead to the deletion
of valid data.

Kind regards,

Adam

On 28 Dec 2017 8:29 p.m., "Mark Goodge"  wrote:

>
>
> On 28/12/2017 19:31, Lester Caine wrote:
>
>> Get the return address right ...
>>
>> On 28/12/17 16:12, Colin Spiller wrote:
>>
>>> I've been adding postcodes in the Bradford BD area using Robert & gregrs
>>> useful tools. I've just noticed that the Shell station at the Rooley
>>> Lane / Rooley Avenue junction BD5 8JR is now reported as having an
>>> incorrect postal unit (the final two letters of the postcode). This
>>> postcode appears widely on the internet for this site, but the RM
>>> postcode finder thinks it should be Rooley Avenue, BD6 1DA.
>>>
>>
>> PAF file has ...
>> Shell Filling Station
>> Rooley Avenue
>> BRADFORD
>> BD6 1DA
>>
>> and BD5 8JR is not listed having been deleted in 2009
>> http://checkmypostcode.uk/bd58jr so the real problem is does one leave
>> the faulty postcode in place because we can't use the PAF data or do we
>> validate postcodes against the codepoint database and remove those that
>> are not listed
>>
>
> It's an interesting conundrum, on several levels. We can certainly
> validate against Codepoint Open or the ONSPD, as these are open data. So if
> they say the postcode is impossible (because it's defunct), then we can
> definitely delete it if we want to.
>
> Replacing it with the correct postcode, though, is harder. We'd need a
> source that isn't derived from PAF. But Googling for this particular
> station, all the sources have the old, incorrect postcode - even Google
> itself! (I would expect they're all using the Shell data, of course).
>
> So that leaves us with three options, at least initially:
>
> 1. Leave it as is. We know it's wrong, but it's consistent with every
> other source, and it's from the only canonical source.
>
> 2. Replace it with the right one. More useful, but potentially risky from
> a licensing perspective.
>
> 3. Delete it and leave the entry with no postcode. Probably the best we
> can do as far as accuracy is concerned (in line with the general principle
> that data is better missing than wrong, if it can't be right), and avoids
> any licence conflict. But this is the least useful for users of the data
> (since, in this case, even the wrong postcode will identify the location in
> practice - for obvious reasons, Royal Mail will deliver to defunct
> postcodes long after they have been deleted, and many sat-navs will work
> with defunct postcodes too).
>
> Maybe the best solution is to leave it alone for now, and see if we can
> persuade Shell to fix it. Deleting the postcode risks it being re-added by
> someone else who spots its absence and decides to be helpful, without
> realising that if they use the RM postcode finder to validate it that isn't
> compatible with OSM's licence.
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb