Re: [Talk-it] Ponte chiuso per lavori

[Andrea Albani]

Il gio 9 ago 2018, 01:34 Martin Koppenhoefer  ha
scritto:

>
> +1, questo metodo mi sembra sostenibile e adatto al breve periodo di
> chiusura (normalmente per pochi giorni non farei niente), manca l’anno 2018
> però, così com’è vorrebbe dire l’ 8-11 agosto di ogni anno.
>

Dimenticanza. Quindi diventa:

vehicle:conditional=no @ (2018 Aug 08 07:00-00:00; 2018 Aug 09-10; 2018 Aug
11 00:00-18:00)

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

[talk-au] FOSS4G SotM Oceania meeting minutes

[John Bryant]

Hi all,

Another edition of the fortnightly meeting minutes from the FOSS4G SotM
organising committee is available here:
https://drive.google.com/open?id=1Dptq91Z5ZeygiYLhw-APYk5Y_pnYTjdp

Key updates:
- Welcome to new committee member Vasiti Soko
- OSGeo will likely provide financial support for the Community Day
- Solid response to workshop submissions, selections to be finalised in the
next few days
- Support for Women's Breakfast event to be provided by Good Mojo fund

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

[Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Gerald Weber]

Oi Pessoal

artigo sobre deteção de vandalismo no OSM:

http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/LIPIcs-GISCIENCE-2018-61.pdf

fico imaginando se a gente conseguiria implementar algo assim em grande
escala

abraço

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

Re: [Talk-br] The social construction of technological stasis: The stagnating data structure in OpenStreetMap

[Gerald Weber]

Oi Paulo

na verdade a estagnação não é somente tecnológica, mas também social ;)

Certamente, o modelo de "todo mundo pode mexer à vontade"  foi importante
há uns 10 anos quando o mapa era um grande vazio e era necessário criar
volume. Mas com a complexidade que temos hoje a lógica já precisava ser
outra. Hoje é preciso criar confiabilidade, e é difícil fazer isto no
modelo atual.

abraço

Gerald

2018-08-05 19:28 GMT-03:00 Paulo Carvalho :

> Como diz o paper, mudar os mais de 50 softwares baseados na atual
> estrutura é inviável.  Seria necessário a OSMF criar um OSM 2 e fazer o *code
> freeze* do OSM atual.  Seria complicado, mas necessário, pois o modelo
> Wiki (no qual o OSM atual se baseia) tem dois sérios defeitos, a saber:
> 1) A revisão é a posteriori.  Deveria ser como em software livre: rever
> antes, publicar depois.  Contribuições ruins podem ser detectadas muito
> tempo depois, levando a um comprometimento sério de partes do mapa
> expandidas a partir delas.
> 2) Não tem um modelo de privilégios crescentes como no Stack Overflow e
> Wikimapia, o que diminui o impacto de edições negligentes ou
> mal-intencionadas.
>
> att,
>
> PC
>
>
> Em 5 de agosto de 2018 11:30, Gerald Weber  escreveu:
>
>> Oi Pessoal
>>
>> artigo fazendo uma análise interessante sobre o OSM e o que o autor chama
>> de estagnação tecnológica:
>>
>> http://journals.sagepub.com/doi/pdf/10.1177/2053951718790591
>>
>> abraço
>>
>> Gerald
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] Ponte chiuso per lavori

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 00:45, Andrea Albani  wrote:
> 
> L'alternativa è l'uso del tag *:conditional documentato qui [1] che io 
> applicherei a tutti i vehicle mettendo poi un tag esplicito per le 
> biciclette. Quindi proporrei:
> 
> bicycle=yes
> vehicle:conditional=no @ (Aug 08 07:00-00:00; Aug 09-10; Aug 11 00:00-18:00)


+1, questo metodo mi sembra sostenibile e adatto al breve periodo di chiusura 
(normalmente per pochi giorni non farei niente), manca l’anno 2018 però, così 
com’è vorrebbe dire l’ 8-11 agosto di ogni anno.


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

Re: [OSM-talk-fr] [Tagging-fr] Proposition - RFC - Les cordes à linges

[François Lacombe]

Bonsoir à tous,

Suite à des observations pertinentes sur la liste internationale tagging,
la proposition a évolué.
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_clamps

La clé proposée line_clamp est remplacée par line_attachment, plus
compréhensible.

Également pole:type a été intégré à la liste des clés à déprécier puis
remplacer (oui c'est une passion de changer les clés :type pour plus
précis).

Le RFC continue encore quelques jours pour être sur de ne rien oublier


Bonne soirée

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

Re: [Talk-it] Ponte chiuso per lavori

[Andrea Albani]

Il giorno mer 8 ago 2018 alle ore 23:29 Giuliano Zamboni <
giuli...@zamboni.pro> ha scritto:

> Guardando il wiki (1)  mi sono fatto l'idea di dover impostare così:
>
> Tag preesistenti:
> Highway: secondary
> Bridge: yes
> Layer: 1
> Maxspeed: 50
> name: Corso Silvio Trentin
> ref: SS14
>
> Ho aggiunto:
> Access: no
> date_on: 2018/08/08
> date_off: 2018/08/11
>
>
>
date_on e date_off sarebbero deprecati, ma è scritto solo nella wiki in
inglese.
L'alternativa è l'uso del tag *:conditional documentato qui [1] che io
applicherei a tutti i vehicle mettendo poi un tag esplicito per le
biciclette. Quindi proporrei:

bicycle=yes
vehicle:conditional=no @ (Aug 08 07:00-00:00; Aug 09-10; Aug 11 00:00-18:00)

Ciao

[1] https://wiki.openstreetmap.org/wiki/Conditional_restrictions
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Projet du mois de juillet 2018 : "armoire haute tension" ?

[François Lacombe]

Bonsoir à tous,

Le 8 août 2018 à 14:07, Julien Lepiller  a écrit :

> Merci, c'est fait ! J'en ai profité pour indiqué le matériau des autres
> poteaux qui sont similaires.
>

Merci, le matériau des supports est également une info intéressante pour la
sensibilité aux aléas climatiques et les études de charges sur les poteaux


> Sur le wiki : https://wiki.openstreetmap.org/wiki/Tag:power%3Dpole

En effet je n'avais pas pensé à regarder.

Je vais embarquer ces valeurs dans la proposition en cours


Bonne soirée

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

Re: [Talk-it] Ponte chiuso per lavori

[Giuliano Zamboni]

  
  
Guardando il wiki (1)  mi sono fatto l'idea di
  dover impostare così:
  
  Tag preesistenti:
  Highway: secondary
  Bridge: yes
  Layer: 1
  Maxspeed: 50
  name: Corso Silvio Trentin
  ref: SS14
  
  Ho aggiunto:
  Access: no
  date_on: 2018/08/08
  date_off: 2018/08/11
  
Ovviamente questo vale
solo per la chiusura totale.
Non ho aggiunto niente per pedoni e bici perchè ci sono le way a
fianco. La modifica riguarda solo la strada.
Se non ho sbagliato e non ci sono suggerimenti domattina carico
il changeset.

Ciao e tutti e grazie

Giuliano (bellazambo)

  
  (1) https://wiki.openstreetmap.org/wiki/IT:Key:access

Il 07/08/2018 15:50, Giuliano Zamboni
  ha scritto:


  
  Scusate,
avrei anche potuto mettervi un link...

https://www.openstreetmap.org/#map=18/45.62544/12.56360

  Ciao
  

  Il 07/08/2018 13:12, Giuliano Zamboni
ha scritto:
  
  

Ciao a tutti,
  il ponte principale tra San Donà di Piave e Musile di Piave
  sulla SS14 è appena stato chiuso per lavori.
  Di seguito il comunicato del comune di Musile arrivato la sera
  prima... (scusate il maiuscolo, è un copia/incolla):
  "SI COMUNICA CHE DA LUNEDI’ 06.08.2018 INIZIERA’ LA
  RISTRUTTURAZIONE DEL PONTE DELLA VITTORIA A CURA DI ANAS SPA.
  DALLE ORE 14.00 DEL GIORNO 06.08.2018 ALLE ORE 14.00 DEL
  07/08/2018 E DALLE ORE 07.00 DEL 08/08/2018 ALLE ORE 18.00 DEL
  11/08/2018 VI SARA’ LA CHIUSURA TOTALE DEL PONTE.
  DAL GIORNO 12.08.2018 FINO AL GIORNO 02.09.2018 IL PONTE
  RIMARRA’ CHIUSO, MA CON UNA CORSIA CENTRALE LIBERA PER IL
  SENSO UNICO ALTERNATO, REGOLATO DA SEMAFORO.
  DAL GIORNO 02.09.2018 E FINO AL GIORNO 07.09.2018 CI SARA’ DI
  NUOVO LA CHIUSURA TOTALE DEL PONTE.
  SI AVVISA CHE DURANTE TUTTO IL PERIODO DEL CANTIERE SARA’
  SEMPRE POSSIBILE ATTRAVERSARE IL PONTE A PIEDI (O CON
  BICICLETTA A MANO) IN ENTRAMBI I SENSI."
  
  E' un periodo di intenso traffico di vacanzieri che
  sicuramente non sono informati.
  Come mi suggerite di mappare la chiusura inserendo anche le
  date di chiusura totale e senso unico alternato?
  I navigatori gestiscono le date di chiusura e apertura lavori?
  
  Se inserissi la chiusura totale e parziale quando viene
  modificata avrebbe validità sul database ma non suoi
  navigatori che aggiornano le mappe mensilmente (come
  OsmAnd)...
  
  Grazie!
  
  Giuliano (bellazambo)
 


___
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: [OSM-talk-fr] Mise à jour des tuiles carto en rade

[Jérôme Seigneuret]

Merci. J'ai toujours des erreurs de mise à jour sur les zooms 16,17,18

Bonne soirée
Jérôme

Le mer. 8 août 2018 à 21:24,  a écrit :

> Impec' vu d'ici.
>
> Jean-Yvon
>
> Le 07/08/2018 à 21:35, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
> écrit :
>
> En voici 2 pour l'exemple.
>
> https://b.tile.openstreetmap.org/18/134095/95646.png
> https://a.tile.openstreetmap.org/18/134096/95647.png
>
> Jérôme
>
> Le mar. 7 août 2018 à 21:25, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> Le 07. 08. 18 à 21:11, Jérôme Seigneuret a écrit :
>> > Il semble qu'on soit toujours en rade de mise à jour des tuiles carto
>> > sur le serveur FR
>> > Savez-vous quand le service sera de nouveau actif?
>> à priori cela devrait pourtant fonctionner
>> tu as l'url d'une tuile qui pose problème ?
>> mais par contre hier j'ai détecter un site qui abuse de l'infra et qui
>> sature à lui tout seul souvent la file d'attente des maj automatique des
>> tuiles... ceci peux expliquer cela.
>> je ne l'ai pas encore bloqué, cela va se faire sous peu
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> 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-it] Aggiornamento mappe su OsmAnd+ e MAPS:ME

[Alessandro Vitali]

Riciao!

Ho installato queste due applicazioni sul mio smartphone e non capisco come
funziona il discorso aggiornamento mappe su MAPS.ME.

Con OsmAnd ad inizio mese mi appare nella sezione "gestione mappe" la
richiesta di aggiornamento di quelle installate, oggi ho appunto aggiornato
quella del trentino ritrovando le modifiche che ho fatto il mese scorso.

Con MAPS.ME nelle impostazioni ho selezionato "scaricamento automatico"...
non so se questo è riferito all'aggiornamento delle mappe Se poi vado
nella sezione "scarica le mappe" mi da la possibilità solo di selezionare
quali mappe scaricare ma non di aggiornarle. Oggi ho provato a
disinstallare e reinstallare quella del trentino ma niente, non sono
presenti le modifiche fatte il mese scorso (al contrario di OsmAnd).

Sbaglio qualcosa o hanno frequenze di aggiornamento differenti? Oppure
centra qualcosa il fatto dello spostamento dei server OSM?


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

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Albani]

Il giorno mer 8 ago 2018 alle ore 21:32 Andrea Albani  ha
scritto:

> C'è ancora una cosa che non torna sul tool.
>
>
Mi rispondo da solo.

Prima di marcare come "confirmed issue" bisogna aprire il link di
brouter-web, fare 1 simulazione di routing (5 nel caso di falsi positivi) e
a questo punto è possibile procedere.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Volker Schmidt]

> >
>
>
> >   highway=service
> >   surface=compacted
> >   bicycle=permissive
> >   foot=permissive
> >   motor_vehicle=private
>
> >
> > https://silicon-verl.de/home/flo/tmp/IMG_20180804_185032.small.jpg
> > https://silicon-verl.de/home/flo/tmp/IMG_20180804_182346.small.jpg
>
> Konkret von den Fotos ausgehend:
In beiden Faellen wird der Weg auch von Autos gelegnetlich benutzt,
vermutlich Kanal-bezogen
Daher

   - highway=service
   - (lanes=1 und oneway=no) *oder* width=3
   - surface=fine_gravel
   - smoothness=good
   - lit=no *(das ist wichtig fuer die Benutzbarkeit)*
   - vehicle=private
   - bicycle=permissive
   - horse=yes|no

Ausserdem wuerde ich die Schranken explizit eintragen, in etwa so:

   - access=private
   - barrier=swing_gate
   - bicycle=permissive
   - foot=yes
   - horse=yes|no
   - maxwidth=1
   - swing_gate:type=single
   - wheelchair=yes|no
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Albani]

C'è ancora una cosa che non torna sul tool.

Se si seleziona uno dei casi segnalati (es. 7.784797,44.535158
 che ho
corretto poco fa) successivamente è possibile confermare che il problema
era effettivamente esistente (e quindi marcalo come fixed cliccando su
"mark as fixed" quando appare)
In realtà cliccando "mark as a confirmed issue" appare un messaggio di
errore un po' criptico:

"marking confirmed requires at least 2 recent nearby waypoints from
BRouter-Web, found: 0"

e quindi il problema rimane ancora nella lista.

Se qualcuno non ha altre interpretazioni a me sembra un bug.

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Mark Goodge]

On 08/08/2018 17:05, Stephen Doerr wrote:

On 8 August 2018, at 15:50, Sean Blanchflower  wrote:

 >I begin to fear I've caused offence in my recent editing, so apologies 
if so. I'm just a keen OSM editor trying to add what I see as a valuable 
omission in its database.


I for one am glad to have the boundaries of the 'real' counties in OSM, 
so thank you for doing this.


I'm sorry, but this is complete and utter bullshit. The "historic" 
county boundaries are no more "real" than the current ones. They were, 
at the time, the administrative boundaries. They are no longer the 
administrative boundaries.


I do appreciate that there are matters where the historic boundaries are 
relevant (primarily genealogical research). But that's not really a 
mapping issue., And the emotional attachment to the pre-1974 boundaries 
is just that - emotion, not based on any objective assessment. And the 
fact that, in retrospect, the 1970s changes were over-reaching and did a 
lot of harm does not change that.


Describing the historic boundaries as "real" is like insisting that we 
map, say, the old Euston station the way it was before it was rebuilt, 
because it was a lot nicer then. It may well be the case that it was. 
But we map what exists now, not what existed in the past and in 
rose-tinted memory. The same with county (and other administrative) 
boundaries. We map what is, not what was.


Mark

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

Re: [Talk-it] Piazzola atterraggio elisoccorso notturno

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 17:19, Andrea Musuruane  wrote:
> 
> Aggiungendo un nodo e specificando quanto segue?
> 
> aeroway=heliport
> emergency=landing_site
> (da https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dhelipad)


se si tratta del campo di calcio, perché aggiungere un ulteriore nodo? Potresti 
aggiungere i tags al leisure=pitch


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

Re: [Talk-us] State Open Data

[Jeffrey Ollie]

I think that this is the data for Iowa that you're looking for:

http://data.iowadot.gov/datasets/historical-road-centerline-files

On Tue, Aug 7, 2018 at 10:22 AM, Clifford Snow 
wrote:

> A few months back I made available Washington State Roads background layer
> available for use in JOSM and iD. (Shoutout to Mapbox for providing free
> hosting of this service.) I would like to add other states but need your
> help finding open data suitable for inclusion in OSM.
>
> To help please update this Google Sheet document [1] with the Open Data
> information. You'll need to give me your email to allow editing but anyone
> should be able to view the information.
>
>
> [1] https://docs.google.com/spreadsheets/d/1exG4LchFlLCn8IAM1Sq1JGo8F6UPS
> nevksjpQ0Y7tTA/edit?usp=sharing
>
>
> Thanks,
> Clifford
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] édition mécanique : nettoyage is_in:continent

[lenny.libre]

Le 08/08/2018 à 01:40, marc marc a écrit :

Bonsoir,

une discussion a lieu ces derniers jours à propos des continents.
ceux-ci, hormis l’antarctique, sont pour le moment représenté par un
nœud car l'étendue de ceux-ci sont imprécis et parfois conflictuel
(parle-t-on d’Europe donc d'un continent politique ? si oui quel est
sa limite vers l'est ou de plaque tectonique et donc d’Eurasie ?)
bref le débat est en cours... et j'ai pas la prétention d'apporter
quelques choses à celui-ci tant les positions sont éloignées.

par contre, pour contourner ce manque d'étendue géographique,
il existe le tag is_in:continent.
cela permet de renseigner qu'un pays ou une partie de celui-ci
est dans tel continent
cependant ce tag pour une raison inconnue se retrouve un peu n'importe
où, il y a par exemple environ 350x ce tag en France continentale
alors qu'il est suffisant d'en avoir un seul sur la relation.

+1
Il me semble aussi que sa présence sur la relation 
https://www.openstreetmap.org/relation/1403916 est suffisante

Leni


Mon message a donc pour but d'informer mon intention de procéder
un nettoyage en France continentale et donc de discuter de celui-ci
avant de le faire comme il se doit :)

PS: c'est quasi toute la variété des is_in qui faudrait nettoyer.
Mais pour d'autre tag, ce serra moins trivial, alors je préfère
y aller par petite étape rapide à discuter et à faire.

Cordialement,
Marc
___
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-de] Wege des WSV an den Kanälen / tagging

[Martin Scholtes]

Hallo,

aus der Zeit, als ich beim WSA Trier mal war, kann ich berichten, das
der WSV entlang der Ufer ca. 2 Meter Land an den Bundeswasserstraßen
Eigentum der WSV sind. Somit befürworte ich deine Anpassung des Tagging.
Jedoch sollte surface je nach Gegebenheiten gesetzt werden und statt
moto_vehicle=private eher ein access=private. Siehe dazu auch hier:
https://www.mapillary.com/map/im/sBv-uHs5j3NjN4Ltb4y9aA

Gruß
Martin


Am 08.08.2018 um 18:16 schrieb Florian Lohoff:
> Hi,
> mir ist auf einer Radtour (Römer Lippe Tour) aufgefallen das das tagging
> der Wege der Wasser und Schiffahrtsverwaltung des Bundes (WSV) entlang
> der Kanäle sehr unterschiedlich ist.
>
> Entlang des Datteln-Hamm-Kanals sind das Cycleways, entlang des
> Datteln-Weser-Kanals sind das tracks.
>
> Es handelt in diesen beiden Fällen um Wege ausgeführt als
> wassergebundene Wegedecke - Meistens so breit das man dort auch
> mit dem Auto fahren könnte (Wenn man denn an den Schranken vorbei käme)
> stellenweise aber auch schmaler so das eben kein 2 Spuriger
> Verkehr fahren kann (Unter Brücken teilweise). Die Wege sind
> Teil der Fernradwege und werden stark von Radfahrern und Fußgängern
> frequentiert.
>
> Die Wege sind für Fußgänger und Radfahrer auf eigene Gefahr freigegeben.
> Mofas und Motorräder sind stellenweise untersagt. 
>
> Ich fände es schön wenn wir das mal vereinheitlichen könnten.
>
> - track
>   Ich halte track für falsch da es sich nicht um überwiegend Land-/
>   oder Forstwirtschaftlich genutzte Wege handelt.
>   Ähnlich der Deichverteidigungswege an der Nordsee.
>
> - cycleway
>   Halte ich ebenfalls für falsch - Das ist ja kein ausgewiesener Radweg
>   sondern ein "Support weg" des Kanals der für Fußgänger und Radfahrer 
>   freigegeben ist.
>
> Daher würde ich so ein tagging passender finden:
>
>   highway=service
>   surface=compacted
>   bicycle=permissive
>   foot=permissive
>   motor_vehicle=private
>
> Wobei ich das mit dem motor_vehicle=private auch doof finde. Das steht
> nirgends, es ist bloss überall durch Poller oder Schranken dafür gesorgt
> das die öffentlichkeit eben mit einem Auto da nicht drauf kommt. 
>
> Exemplarische Beispiele:
>
> https://silicon-verl.de/home/flo/tmp/IMG_20180804_185032.small.jpg
> https://silicon-verl.de/home/flo/tmp/IMG_20180804_182346.small.jpg
>
> Flo
>
>
> ___
> 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: [OSM-talk] highway=* + area=yes vs area:highway=*

[Tobias Knerr]

On 08.08.2018 12:49, Tomasz Wójcik wrote:
> Due to our rules, that we shouldn't have 2 active tagging
> schemes for the same feature

These tagging schemes are for 2 different real-world features:
* roads/paths (i.e. linear features with a direction)
* plazas/squares (i.e. open areas where people will walk across in all
directions)

Linear roads/paths are mapped as highway=* ways, optionally with an
additional area:highway=* polygon.

Plazas/squares are mapped as highway=* + area=yes polygons.

So the area:highway key is never an alternative to highway polygons with
area=yes! In any given situation, only one or the other will be correct.

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

[Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

Hi,
mir ist auf einer Radtour (Römer Lippe Tour) aufgefallen das das tagging
der Wege der Wasser und Schiffahrtsverwaltung des Bundes (WSV) entlang
der Kanäle sehr unterschiedlich ist.

Entlang des Datteln-Hamm-Kanals sind das Cycleways, entlang des
Datteln-Weser-Kanals sind das tracks.

Es handelt in diesen beiden Fällen um Wege ausgeführt als
wassergebundene Wegedecke - Meistens so breit das man dort auch
mit dem Auto fahren könnte (Wenn man denn an den Schranken vorbei käme)
stellenweise aber auch schmaler so das eben kein 2 Spuriger
Verkehr fahren kann (Unter Brücken teilweise). Die Wege sind
Teil der Fernradwege und werden stark von Radfahrern und Fußgängern
frequentiert.

Die Wege sind für Fußgänger und Radfahrer auf eigene Gefahr freigegeben.
Mofas und Motorräder sind stellenweise untersagt. 

Ich fände es schön wenn wir das mal vereinheitlichen könnten.

- track
  Ich halte track für falsch da es sich nicht um überwiegend Land-/
  oder Forstwirtschaftlich genutzte Wege handelt.
  Ähnlich der Deichverteidigungswege an der Nordsee.

- cycleway
  Halte ich ebenfalls für falsch - Das ist ja kein ausgewiesener Radweg
  sondern ein "Support weg" des Kanals der für Fußgänger und Radfahrer 
  freigegeben ist.

Daher würde ich so ein tagging passender finden:

highway=service
surface=compacted
bicycle=permissive
foot=permissive
motor_vehicle=private

Wobei ich das mit dem motor_vehicle=private auch doof finde. Das steht
nirgends, es ist bloss überall durch Poller oder Schranken dafür gesorgt
das die öffentlichkeit eben mit einem Auto da nicht drauf kommt. 

Exemplarische Beispiele:

https://silicon-verl.de/home/flo/tmp/IMG_20180804_185032.small.jpg
https://silicon-verl.de/home/flo/tmp/IMG_20180804_182346.small.jpg

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Nick Whitelegg]

... even though technically, it was not Greater Manchester when I was born, it 
was in my earliest memories.


Nick



From: Nick Whitelegg 
Sent: 08 August 2018 17:03
To: Talk-GB@openstreetmap.org; co...@thespillers.org.uk
Subject: Re: [Talk-GB] 'historic' county boundaries added to the database


I think these things are at least partly a product of what generation you 
belong to.

I'm of the generation that was too young to remember pre-1974 but was well into 
my twenties by the next reorganisation. Consequently I think of Manchester as 
being in Greater Manchester (and that I was both born in and lived the first 5 
years or so of my life in Greater Manchester) and Bournemouth as being in 
Dorset, and not Hampshire.

But, on the other hand, I think of Southampton, where I live now, as firmly in 
Hampshire even though technically it's not part of HCC.

The only exceptions are that I think of Rutland as Rutland and Herefordshire 
and Worcestershire as their own counties - and not combined.

Basically, the current "ceremonial counties" correspond very closely to what 
county I think of something as being in!

Nick



From: Colin Spiller 
Sent: 08 August 2018 16:29:15
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] 'historic' county boundaries added to the database

Here in Yorkshire, people are very possessive (if that's the right
word!) about the old county boundary (i.e. pre 1974). Many people are
very aware of the problem (as they see it) that certain parts of
Yorkshire have been transferred to (or 'stolen by') Lancashire, or other
counties. They still think of the 3 Ridings as current in some cases.

And Liverpool and Manchester are still parts of Lancashire according to
some!

Colin


On 08/08/18 10:55, Mark Goodge wrote:
>
>
> On 07/08/2018 20:48, Dave F wrote:
>> Hi
>>
>> User smb1001 is currently adding county boundary relations with
>> boundary=historic through out the UK:
>> http://overpass-turbo.eu/s/ASf (May take a while to run)
>>
>> Changeset discussion:
>> https://www.openstreetmap.org/changeset/61410203
>>
>>  From the historic wiki page
>> "historic objects should not be mapped as it is outside of scope of OSM"
>>
>> Frankly I don't buy his comments. The problem is where to stop? Do we
>> have ever iteration of every boundary change since time immemorial?
>> Then what about buildings, roads, or coastline changes etc? The
>> database would become unmanageable for editors (it already is if
>> zoomed out too far).
>
> I agree that "historic" boundaries don't belong in OSM. They have
> value for historic researchers, but, as you say, that's not what OSM
> is about.
>
> It's also flat out incorrect to say that historic boundaries are
> "immutable". Although it is true that there were massive changes in
> the 1970s and a lot more since then, the idea that the historic (or
> "traditional") counties were stable throughout history is just
> myth-making. A lot of what people think of as the historic county
> boundaries are, in fact, a Victorian creation. And even they didn't
> leave them alone!
>
> I do think, though, that there's a case for including the current
> ceremonial and preserved county boundaries. These have a defined and
> relevant meaning here and now, even if it's a less common one than
> administrative boundaries such as counties, districts and parishes.
> Maybe the people adding historic boundaries to OSM could be nudged in
> that direction instead.
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

--
Colin Spiller
co...@thespillers.org.uk


___
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: [Talk-GB] 'historic' county boundaries added to the database

[Stephen Doerr]

On 8 August 2018, at 15:50, Sean Blanchflower  wrote:

>I begin to fear I've caused offence in my recent editing, so apologies if so. 
>I'm just a keen OSM editor trying to add what I see as a valuable omission in 
>its database.

I for one am glad to have the boundaries of the 'real' counties in OSM, so 
thank you for doing this.

Steve

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

Re: [Talk-cz] Neco mezi Vespucci a OsmAnd pro editaci v terenu

[mahdi1234]

Nejnovejsi verze OsmAndu 3.1 mimo jine pridava podporu pro editaci
non-point objektu, teda napr hotel/restaurace prirazena k budove, super.

mahdi

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Colin Spiller]

Here in Yorkshire, people are very possessive (if that's the right 
word!) about the old county boundary (i.e. pre 1974). Many people are 
very aware of the problem (as they see it) that certain parts of 
Yorkshire have been transferred to (or 'stolen by') Lancashire, or other 
counties. They still think of the 3 Ridings as current in some cases.


And Liverpool and Manchester are still parts of Lancashire according to 
some!


Colin


On 08/08/18 10:55, Mark Goodge wrote:



On 07/08/2018 20:48, Dave F wrote:

Hi

User smb1001 is currently adding county boundary relations with 
boundary=historic through out the UK:

http://overpass-turbo.eu/s/ASf (May take a while to run)

Changeset discussion:
https://www.openstreetmap.org/changeset/61410203

 From the historic wiki page
"historic objects should not be mapped as it is outside of scope of OSM"

Frankly I don't buy his comments. The problem is where to stop? Do we 
have ever iteration of every boundary change since time immemorial? 
Then what about buildings, roads, or coastline changes etc? The 
database would become unmanageable for editors (it already is if 
zoomed out too far).


I agree that "historic" boundaries don't belong in OSM. They have 
value for historic researchers, but, as you say, that's not what OSM 
is about.


It's also flat out incorrect to say that historic boundaries are 
"immutable". Although it is true that there were massive changes in 
the 1970s and a lot more since then, the idea that the historic (or 
"traditional") counties were stable throughout history is just 
myth-making. A lot of what people think of as the historic county 
boundaries are, in fact, a Victorian creation. And even they didn't 
leave them alone!


I do think, though, that there's a case for including the current 
ceremonial and preserved county boundaries. These have a defined and 
relevant meaning here and now, even if it's a less common one than 
administrative boundaries such as counties, districts and parishes. 
Maybe the people adding historic boundaries to OSM could be nudged in 
that direction instead.


Mark

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


--
Colin Spiller
co...@thespillers.org.uk


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

Re: [Talk-in] tasks.openstreetmap.in is down

[Chetan H A]

Thanks Sajjad and Sanjay for fixing it!

On Wed, 8 Aug 2018, 8:43 p.m. Sajjad Anwar,  wrote:

> Hi everyone,
>
> Sorry about the delay to respond to this issue - we've all been away and
> pretty busy. We fixed just now (
> https://github.com/osm-in/osm-tasking-manager2/issues/10). You should now
> be able to login and continue mapping http://tasks.openstreetmap.in/
>
> Happy mapping!
>
> Cheers,
> Sajjad
>
> On Wed, Aug 8, 2018 at 3:35 AM Craig Dsouza  wrote:
>
>> Yep, I'm having the same issue at login
>>
>> On Wed, Aug 1, 2018 at 6:25 PM Nikhil VJ  wrote:
>>
>>> Hello,
>>>
>>> Apologies if this is a repeat post.. I'm not seeing these mailing lists
>>> often.
>>>
>>> The India HOT Tasking Manager site http://tasks.openstreetmap.in is not
>>> working when we try to login. Getting a generic error message
>>>
>>> > "The server encountered an internal error or misconfiguration and was
>>> unable to complete your request."
>>>
>>> And at some places, advertisement popups are spawning, there might be
>>> some malware scripts at play.
>>>
>>> A fellow mapper who had been participating in our project
>>>  there just wrote to me about
>>> it.
>>>
>>> Other tasking manager sites I checked are up and running properly.
>>>
>>>
>>> --
>>> Cheers,
>>> Nikhil VJ
>>> +91-966-583-1250
>>> Pune, India
>>> Website 
>>> DataMeet Pune chapter 
>>> Self-designed learner at Swaraj University <
>>> http://www.swarajuniversity.org>
>>> Payment / Contribute 
>>>
>>
>>
>> --
>>
>> *Independent Researcher - Water Resources Management*
>> *Open Water Data Project*
>> Web App: https://water-data-web-app.appspot.com/
>> Website: https://datameet-pune.github.io/open-water-data/
>> *My Blog*: unravellingindia.in
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Piazzola atterraggio elisoccorso notturno

[Andrea Musuruane]

Ciao,

2018-08-08 17:10 GMT+02:00 Gianluca Boero :

> Ciao a tutti...
>
> E' stata inaugurata nel comune di Bricherasio (To) una piazzola di
> atterraggio notturno per l'elisoccorso. Tale piazzola è il campo di calcio,
> il quale tramite un codice di sblocco situato all'ingresso, attivabile da
> personale di terra specializzato nei soccorsi, apre la struttura e
> automaticamente accende l'illuminazione, permettendo all'elicottero di
> atterrare in completa sicurezza in zona illuminata.
>
> Secondo il discorso inaugurale, in Piemonte vi sono già altre strutture
> del genere. Ne conoscete?
>

Conosco quelle di Santhià e Ivrea.


> Ora essendo il campo di calcio già taggato come Leisure=pitch e
> sport=soccer cosa si potrebbe aggiungere per identificare questa ulteriore
> utilizzazione? Calcolando che non vi sono "ore ufficiali" di atterraggio,
> in quanto in inverno ovviamente il buio sopraggiunge prima.
>
>
Aggiungendo un nodo e specificando quanto segue?

aeroway=heliport
emergency=landing_site
(da https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dhelipad)


Ciao,

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

Re: [Talk-in] tasks.openstreetmap.in is down

[Sajjad Anwar]

Hi everyone,

Sorry about the delay to respond to this issue - we've all been away and
pretty busy. We fixed just now (
https://github.com/osm-in/osm-tasking-manager2/issues/10). You should now
be able to login and continue mapping http://tasks.openstreetmap.in/

Happy mapping!

Cheers,
Sajjad

On Wed, Aug 8, 2018 at 3:35 AM Craig Dsouza  wrote:

> Yep, I'm having the same issue at login
>
> On Wed, Aug 1, 2018 at 6:25 PM Nikhil VJ  wrote:
>
>> Hello,
>>
>> Apologies if this is a repeat post.. I'm not seeing these mailing lists
>> often.
>>
>> The India HOT Tasking Manager site http://tasks.openstreetmap.in is not
>> working when we try to login. Getting a generic error message
>>
>> > "The server encountered an internal error or misconfiguration and was
>> unable to complete your request."
>>
>> And at some places, advertisement popups are spawning, there might be
>> some malware scripts at play.
>>
>> A fellow mapper who had been participating in our project
>>  there just wrote to me about
>> it.
>>
>> Other tasking manager sites I checked are up and running properly.
>>
>>
>> --
>> Cheers,
>> Nikhil VJ
>> +91-966-583-1250
>> Pune, India
>> Website 
>> DataMeet Pune chapter 
>> Self-designed learner at Swaraj University <
>> http://www.swarajuniversity.org>
>> Payment / Contribute 
>>
>
>
> --
>
> *Independent Researcher - Water Resources Management*
> *Open Water Data Project*
> Web App: https://water-data-web-app.appspot.com/
> Website: https://datameet-pune.github.io/open-water-data/
> *My Blog*: unravellingindia.in
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-us] State Open Data

[Clifford Snow]

Adam,
Thanks for adding Vermont.

At some point I'd like to do like you did with surfaces. One of the
problems I run into is that every agency seems to have a different list of
surfaces. We'd should probably try to create a conversion chart to map
different names into OSM surface types.

For example, USFS roads has the following surface types

 AC - ASPHALT

 AGG - CRUSHED AGGREGATE OR GRAVEL

 AGG - LIMESTONE

 AGG - SCORIA

 BST - BITUMINOUS SURFACE TREATMENT

 CSOIL - COMPACTED SOIL

 FSOIL - FROZEN SOIL

 IMP - IMPROVED NATIVE MATERIAL

 NATIVE MATERIAL

 NAT - NATIVE MATERIAL

 OTHER - OTHER

 PCC - PORTLAND CEMENT CONCRETE

 PIT - PIT RUN SHOT ROCK

 P - PAVED

 SOD - GRASS


>From Okanogan county in Washington they have

 D

 d

 null (which has the highest count)

 P

 G

The states metadata can help us build a conversion to OSM surface types;


Clifford




On Wed, Aug 8, 2018 at 7:49 AM Adam Franco  wrote:

> I've added Vermont's center-line
>  info to
> the spreadsheet. As someone who does a lot of filtering of OSM roads based
> on surface, exposing surface info to a broader group of editors would be a
> fabulous win. Thanks for heading in this direction!
>
> To do my own surface entry I've resorted to side-by side JOSM and QGIS
> windows with the latter showing a color-coded road-centerline file. As can
> be imagined, most people won't go to this effort and hence US road-surface
> data in OSM is pretty patchy to say the least.
>
>
>
>
> On Tue, Aug 7, 2018 at 11:32 PM, Elliott Plack 
> wrote:
>
>> Maryland’s Transportation Basemap is already availability in iD and JOSM
>> as an imagery source. We also have a slew of open datasets including
>> centerline and speed limits. I’ll take a look at the doc and add some.
>> http://data.imap.maryland.gov/datasets?q=transportation
>>
>> Kudos on getting this together!
>> On Tue, Aug 7, 2018 at 23:27 Paul Johnson  wrote:
>>
>>>
>>>
>>> On Tue, Aug 7, 2018 at 9:00 PM, Clifford Snow 
>>> wrote:
>>>
 Ian,


 On Tue, Aug 7, 2018 at 9:30 AM Ian Dees  wrote:

> Thanks for putting this together, Clifford!
>
> I was collecting street centerline data as part of OpenAddresses a
> while ago here: https://github.com/openaddresses/centerlines
>
> I'm happy to add you to this repo if you want to use this repo or feel
> free to pull from this repo into your spreadsheet.
>
> My goal with this was to pull all this data into a single,
> country-wide layer to map in OSM with. I'm happy to help you down that
> path, if that's what you're thinking.
>
>
 That is exactly my goal - get all of the states with open data into a
 background image that people could use to trace from, much like your TIGER
 2017 and previous years. My initial attempt will be just centerlines with
 street names. Later we need to add surface and other details.

>>>
>>>
>>> This could present a feedback loop in Oklahoma, since OklaDOT's portal
>>> can use (and in some datasets, does use by default) OSM.
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>> --
>> Elliott Plack
>> http://elliottplack.me
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-it] Piazzola atterraggio elisoccorso notturno

[Gianluca Boero]

Ciao a tutti...

E' stata inaugurata nel comune di Bricherasio (To) una piazzola di 
atterraggio notturno per l'elisoccorso. Tale piazzola è il campo di 
calcio, il quale tramite un codice di sblocco situato all'ingresso, 
attivabile da personale di terra specializzato nei soccorsi, apre la 
struttura e automaticamente accende l'illuminazione, permettendo 
all'elicottero di atterrare in completa sicurezza in zona illuminata.


Secondo il discorso inaugurale, in Piemonte vi sono già altre strutture 
del genere. Ne conoscete?


Ora essendo il campo di calcio già taggato come Leisure=pitch e 
sport=soccer cosa si potrebbe aggiungere per identificare questa 
ulteriore utilizzazione? Calcolando che non vi sono "ore ufficiali" di 
atterraggio, in quanto in inverno ovviamente il buio sopraggiunge prima.


Grazie...

Gianluca


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

Re: [Talk-cz] rychlost

[mahdi1234]

Taky muzes zkusit
https://www.openstreetbrowser.org/#map=15/49.4006/15.5908=car_maxspeed

Z aplikaci pro telefon pak treba streetcomplete ma maxspeed quest -
https://play.google.com/store/apps/details?id=de.westnordost.streetcomplete

mahdi

Jan Martinec wrote on 08/08/2018 04:16 PM:
> Tady třeba:
> http://product.itoworld.com/map/125?lon=14.43851=50.08013=14
>
> Zdar,
> HPM
>
> Dne 8. 8. 2018 16:12 napsal uživatel "marek"  >:
>
> Existuje nějaká ulitka, která zobrazí v mapě ulice, kde nejsou
> ještě zadány rychlostní limity?
>  
> Marek Polák
>  
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Sean Blanchflower]

Hi all,
I'm smb1001 and have been adding the traditional county boundaries
recently. DaveF kindly let me know of the discussion thread here so I've
joined Talk-GB to add my side of things.

I'm not alone in thinking the traditional county boundaries have a place on
current maps. It's unfortunate here that these counties are known as
'historic counties' as this implies that they are no longer extant. The
debate as to their current utility or their immutability is not one I feel
is relevant here as there are arguments on both sides, but the Association
of British Counties summarises it more succinctly than I could in any case
(see https://en.wikipedia.org/wiki/Association_of_British_Counties and the
many links therein).

I have no intention of adding any "historic" boundaries beyond the
counties. I settled on the (static) definition of "historic counties" used
by the Ordnance Survey and UK government and was going to stop there.

I would also have never started my efforts if the results would have
littered invisible lines all over the map. Similarly, if there were an
authoritative trace that could be imported then I'd agree that that also
should be blocked. The reason I've been doing it is that 99% of the ways
required to create the counties are already in OSM. Pretty much all I've
been doing is adding existing (administrative) boundary ways to these new
'historic' relations alongside the 'ceremonial' and myriad 'administrative'.

(As an aside, I would also have never started my efforts if I hadn't been
inspired by finding that the same had been done for other countries.)

I fully agree with Lester's comments on OHM in all this. Without the
presence of the 'current' OSM database in OHM, it's impossible to get any
traction there. For example I can't actually add the traditional counties
to OHM without the current OSM administrative boundaries (county and
parish). Then again, as he said, if the current OSM set were put there to
do so, it ends up duplicating the site.

I also agree with DaveF that to add every iteration of former boundaries is
not for OSM, but I would argue that the addition of the traditional
counties as defined by this current definition does not fall into that.
After all, certain councils have already been erecting road signs
indicating the presence of these county boundaries so why would we not
reflect that.

I begin to fear I've caused offence in my recent editing, so apologies if
so. I'm just a keen OSM editor trying to add what I see as a valuable
omission in its database.

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

Re: [Talk-cz] rychlost

[Jan Martinec]

...ale co jsem to teď zkoušel, tak je to nějak výrazně pomalejší, než
pamatuju.

Jednodušší mi připadá v JOSM zapnout filtr na zobrazení jen highway=*, a k
němu druhý na skrytí maxspeed=*; případně k tomu tahat z Overpassu jenom
way[highway]; tu ITO mapu jsem využil vlastně jen jako přehledku.

Zdar,
HPM

Dne st 8. 8. 2018 16:16 uživatel Jan Martinec  napsal:

> Tady třeba:
> http://product.itoworld.com/map/125?lon=14.43851=50.08013=14
>
> Zdar,
> HPM
>
> Dne 8. 8. 2018 16:12 napsal uživatel "marek" :
>
> Existuje nějaká ulitka, která zobrazí v mapě ulice, kde nejsou ještě
> zadány rychlostní limity?
>
> Marek Polák
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] rychlost

[Jan Martinec]

Tady třeba:
http://product.itoworld.com/map/125?lon=14.43851=50.08013=14

Zdar,
HPM

Dne 8. 8. 2018 16:12 napsal uživatel "marek" :

Existuje nějaká ulitka, která zobrazí v mapě ulice, kde nejsou ještě zadány
rychlostní limity?

Marek Polák


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

[Talk-cz] rychlost

[marek]

Existuje nějaká ulitka, která zobrazí v mapě ulice, kde nejsou ještě zadány 
rychlostní limity?
 
Marek Polák
 

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

Re: [Talk-us] State Open Data

[Adam Franco]

I've added Vermont's center-line
 info to
the spreadsheet. As someone who does a lot of filtering of OSM roads based
on surface, exposing surface info to a broader group of editors would be a
fabulous win. Thanks for heading in this direction!

To do my own surface entry I've resorted to side-by side JOSM and QGIS
windows with the latter showing a color-coded road-centerline file. As can
be imagined, most people won't go to this effort and hence US road-surface
data in OSM is pretty patchy to say the least.




On Tue, Aug 7, 2018 at 11:32 PM, Elliott Plack 
wrote:

> Maryland’s Transportation Basemap is already availability in iD and JOSM
> as an imagery source. We also have a slew of open datasets including
> centerline and speed limits. I’ll take a look at the doc and add some.
> http://data.imap.maryland.gov/datasets?q=transportation
>
> Kudos on getting this together!
> On Tue, Aug 7, 2018 at 23:27 Paul Johnson  wrote:
>
>>
>>
>> On Tue, Aug 7, 2018 at 9:00 PM, Clifford Snow 
>> wrote:
>>
>>> Ian,
>>>
>>>
>>> On Tue, Aug 7, 2018 at 9:30 AM Ian Dees  wrote:
>>>
 Thanks for putting this together, Clifford!

 I was collecting street centerline data as part of OpenAddresses a
 while ago here: https://github.com/openaddresses/centerlines

 I'm happy to add you to this repo if you want to use this repo or feel
 free to pull from this repo into your spreadsheet.

 My goal with this was to pull all this data into a single, country-wide
 layer to map in OSM with. I'm happy to help you down that path, if that's
 what you're thinking.


>>> That is exactly my goal - get all of the states with open data into a
>>> background image that people could use to trace from, much like your TIGER
>>> 2017 and previous years. My initial attempt will be just centerlines with
>>> street names. Later we need to add surface and other details.
>>>
>>
>>
>> This could present a feedback loop in Oklahoma, since OklaDOT's portal
>> can use (and in some datasets, does use by default) OSM.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> Elliott Plack
> http://elliottplack.me
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] State Open Data

[Clifford Snow]

Elliott,
Thanks - I've added Maryland into the spreadsheet.

Clifford

On Tue, Aug 7, 2018 at 9:32 PM Elliott Plack 
wrote:

> Maryland’s Transportation Basemap is already availability in iD and JOSM
> as an imagery source. We also have a slew of open datasets including
> centerline and speed limits. I’ll take a look at the doc and add some.
> http://data.imap.maryland.gov/datasets?q=transportation
>
> Kudos on getting this together!
> On Tue, Aug 7, 2018 at 23:27 Paul Johnson  wrote:
>
>>
>>
>> On Tue, Aug 7, 2018 at 9:00 PM, Clifford Snow 
>> wrote:
>>
>>> Ian,
>>>
>>>
>>> On Tue, Aug 7, 2018 at 9:30 AM Ian Dees  wrote:
>>>
 Thanks for putting this together, Clifford!

 I was collecting street centerline data as part of OpenAddresses a
 while ago here: https://github.com/openaddresses/centerlines

 I'm happy to add you to this repo if you want to use this repo or feel
 free to pull from this repo into your spreadsheet.

 My goal with this was to pull all this data into a single, country-wide
 layer to map in OSM with. I'm happy to help you down that path, if that's
 what you're thinking.


>>> That is exactly my goal - get all of the states with open data into a
>>> background image that people could use to trace from, much like your TIGER
>>> 2017 and previous years. My initial attempt will be just centerlines with
>>> street names. Later we need to add surface and other details.
>>>
>>
>>
>> This could present a feedback loop in Oklahoma, since OklaDOT's portal
>> can use (and in some datasets, does use by default) OSM.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> Elliott Plack
> http://elliottplack.me
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 14:40, djakk djakk  wrote:
> 
> I don’t get why highway=footway + area=yes is considered as wrong tagging !



because an area is not a “way”, a way implies linearity.


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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 12:49, Tomasz Wójcik  wrote:
> 
> Due to our rules, that we shouldn't have 2 active tagging schemes for the 
> same feature, so we should discuss this topic. 


can you point me to this rule? Is it documented somewhere? While I agree it is 
preferable to not have different tags for the exact same meaning, it is still 
occurring with a fee tags and there isn’t a huge problem with it (compared to 
having the same tag with different intended meaning).

Btw: in the beginning it was rather common to have different values with the 
same meaning, e.g. yes, true and 1.

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 13:54, Colin Smale wrote:
There are plenty of examples of "former" objects in OSM - closed pubs, 
railway alignments etc. They are only still there because they are 
perceived to have some kind of relevance in the present day. Can a case 
be made that these historic counties are still "relevant" today?


I'm listening to the steam trains pulling in and out of Broadway station 
at the moment. This was a 'disused' line and there was talk about 
removing that sort of data from OSM. The line out of Broadway goes on 
north and still has a designated use of 'disused railway'. I don't know 
if the line will ever be extended, but in some peoples minds it's on the 
cards as it could eventually link to Stratford Upon Avon. That end of 
the line has now been built on so a new terminus would have to stop 
short, but knowing where the line used to run through that house estate 
is interesting to some.


Even a pub has a place in the tracking of genealogical data and if one 
has some means of showing a current map with the location of previous 
events it's a useful tool. OHM is trying to do that, but since every 
change in OSM has to be mirrored to OHM I find this very counter 
productive ... YES there is a need for separate layers of data such as 
the battles of the second world war, but all should have a single base 
in OSM and where key parts of the two combine, the current OSM map 
continues to display them. Purely using OSM data to show the development 
of a town over time potentially needs very little 'historic' data other 
then 'start_date' ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Tom Pfeifer]

On 08.08.2018 12:49, Tomasz Wójcik wrote:
As highway=footway etc. tags are set to "should not be used on areas" on Wiki, and mapping them in 
combination with area=yes is not documented at all and considered as wrong tagging by part of users, 
there is a key "area:highway=*" (133k uses at the moment). Part of users still map footway areas as 
a combination anyway, propably because it's rendered by default style. Due to our rules, that we 
shouldn't have 2 active tagging schemes for the same feature, so we should discuss this topic.


There is nothing on the wiki page that explicitly discourages or deprecates the use of highway tags 
on an area, except the flag in the template that defines that a closed loop means it is not filled, 
in the absence of other tagging.


area=yes is the traditional tagging then to distinguish a closed loop from an 
filled area.

"some closed ways ... are assumed to be areas, but others, such as highway=footway are not, being 
treated as linear features instead, except when there is also an area=yes tag." [1]


"The area=yes tag is required for some closed ways when used to define an Area 
(polygon)"

area=yes is used nearly a million times, 300k with highway*

area=yes and highway:area=* have different purposes, the first for the occasional filled polygon, 
the latter for systematically mapping highway width and shape.


Thus, area=yes is _well_ documented, and I see no reason to change that.

[1] https://wiki.openstreetmap.org/wiki/Area
[2] https://wiki.openstreetmap.org/wiki/Key:area

tom

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

Re: [OSM-talk-be] JOSM preset "Mapping in Belgium" updated (Santens Seppe)

[Marc Gemis]

is gebeurd.

Ik dacht dat ik dat een tijdje geleden al had aangepast, maar ik had
blijkbaar enkel de 2 andere tags vervangen door emergency=life_ring
On Tue, Aug 7, 2018 at 2:17 PM Philippe Casteleyn
 wrote:
>
> Ik zou
>
> 
>
> weg laten.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Dave F]

On 08/08/2018 13:54, Colin Smale wrote:


On 2018-08-08 14:17, Dave F wrote:


Hi

On 08/08/2018 12:14, Colin Smale wrote:
If this (probably completely static) dataset is used as a baseline, 
at least these relations would have a verifiable source.


https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/boundary-line.html#Historicdownload

"The links above represent counties based on historic records and 
mapping circa 1888 and using the primary sources of the Local 
Government (England and Wales) Act 1888, the Local Government 
(Scotland) Act 1889 and the Sheriffs Act 1887. "




Those are fairly inaccurate snap shots of what thought to be accurate 
at that just date. As Mark G pointed out it's a ridiculous notion to 
believe those boundaries can be extrapolated back to "Saxon times".


They would be accurate according to the source (viz. OS). 1888 is of 
course nowhere near "Saxon times".


The contributor adding them has added no date & claims they're accurate 
back to the Saxon invasion. Which is ridiculous.


If the OS-provided data were to be used as the source of the "historic 
county boundaries" would that not be grounds for a possible compromise 
here?


Again, where to stop? No data is destroyed. OHM provides an equivalent 
database to store old data if needed.


There are plenty of examples of "former" objects in OSM - closed pubs, 
railway alignments etc. They are only still there because they are 
perceived to have some kind of relevance in the present day. Can a 
case be made that these historic counties are still "relevant" today?  
I would like to hear smb1001's take on this.


Pubs often reopen.
Disused/razed/abandoned railways should be removed from the OSM database 
*but* only if they're not tagged along with current features (cycleway, 
embankments, bridges etc)


smb1001 is aware of this discussion. His views are in the changeset 
comments.


Cheers
DaveF


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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 12:59, Dave F wrote:
How often do you believe people will actually want historic data? 
Organizations archive for a reason. Consider your house, how things you 
don't use will get shoved to the back of the cupboard/shed.
I live in a Roman city, the editors struggle to display current data. 
Imagine what it would be like if *everything* was shown back to the days 
of Emperor Nero.


We have the same problem all over the place in keeping historic data 
accessible. The argument is always 'How many people will use it' or 
'Does it matter if we ignore that' :(


Even providing verifiable timestamps for historic events is a gamble 
since the timezone database hides verified data prior to 1970 'because 
it's outside the remit'! In which case one needs a reliable source for 
time offsets even as recently as the 2nd world war because those 
provided by TZ are known to be wrong ... but nobody provides it :(


The fact that there was Roman settlement in an area is very useful data 
for a planning department to know if a full archaeological report is 
needed. My own genealogical research would be helped if CURRENT data had 
a start_date and then one could see if a street being referenced 
actually existed at the time ... that is one for OSM rather than OHM 
except the street may have been 'moved' or renamed, at which time the 
historic element may become important. And knowing if the street on the 
current map was in a different county is also important data. But where 
do you go to find out.


There is no clear distinction as to what is current and what is historic 
data. They intertwine and a single documented view of all the data 
including that which is becoming history on a daily basis should be the 
target, rather than saying 'It's too difficult so lets ignore it'. It's 
not difficult for a computer to manage and if people have the desire to 
start filling in all the gaps then they should be supported, not told to 
go away?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Maarten Deen]

Then I still don't understand the problem. A closed way tagged with 
highway=* will by default route. A closed way with area:highway=* will 
not. You'll have to introduce logic in the router to do so.


Regards,
Maarten

On 2018-08-08 14:49, john whelan wrote:

I don’t get why highway=footway + area=yes is considered as wrong

tagging !

The problem is consistency.  If the renderers and routers don't
understand your tagging then it is less visible.

Cheerio John

On 8 August 2018 at 08:40, djakk djakk  wrote:


I don’t get why highway=footway + area=yes is considered as wrong
tagging !

djakk

Le mer. 8 août 2018 à 12:52, Tomasz Wójcik  a
écrit :


As highway=footway etc. tags are set to "should not be used on
areas" on Wiki, and mapping them in combination with area=yes is
not documented at all and considered as wrong tagging by part of
users, there is a key "area:highway=*" (133k uses at the moment).
Part of users still map footway areas as a combination anyway,
propably because it's rendered by default style. Due to our rules,
that we shouldn't have 2 active tagging schemes for the same
feature, so we should discuss this topic.

I vote for area:highway=* key, because it's simpler, and it gives
a possibility to show also street areas with crossings in the
future.

* Wiki with specyfications of a:h=* for certain keys:
https://wiki.openstreetmap.org/wiki/Key:area:highway [1]
* TagInfo: https://taginfo.openstreetmap.org/keys/area:highway [2]
* area:highway=* visualisation: http://osmapa.pl/w/area [3]

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


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




Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:area:highway
[2] https://taginfo.openstreetmap.org/keys/area:highway
[3] http://osmapa.pl/w/area
[4] 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] BRouter Suspect Scanner

[Andrea Albani]

Il giorno mer 8 ago 2018 alle ore 12:28 Andrea Musuruane 
ha scritto:

>
> L'ho sistemato io poco fa. In tutta l'area le relazioni straight_on erano
> errate.
>
> Concordo che i tempi di aggiornamento sono un po' lunghi. Però piuttosto
> che niente, meglio piuttosto ;-)
>
>



Ho messo a posto anch'io a posto qualche restriction in zona Fossano...su
brouter web client non appare ancora nulla,  ma su restriction validator
[1] dopo un po' la situazione era aggiornata.

[1] https://restrictions.morbz.de/#18/44.48165/7.68914

PS cmq bel tool. Grazie per la segnalazione ad Arndt.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-br] Digest Talk-br, volume 119, assunto 4

[Luis Bahiana]

Parabéns Arlindo excelente iniciativa !

Em Qua, 8 de ago de 2018 09:01, 
escreveu:

> Enviar submissões para a lista de discussão Talk-br para
> talk-br@openstreetmap.org
>
> Para se cadastrar ou descadastrar via WWW, visite o endereço
> https://lists.openstreetmap.org/listinfo/talk-br
> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
> corpo da mensagem para
> talk-br-requ...@openstreetmap.org
>
> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
> endereço
> talk-br-ow...@openstreetmap.org
>
> Quando responder, por favor edite sua linha Assunto assim ela será
> mais específica que "Re: Contents of Talk-br digest..."
>
>
> Tópicos de Hoje:
>
>1. [RJ] In Loco - Mapas do MPRJ (Arlindo Pereira)
>
>
> --
>
> Message: 1
> Date: Tue, 7 Aug 2018 13:09:08 -0300
> From: Arlindo Pereira 
> To: 
> Subject: [Talk-br] [RJ] In Loco - Mapas do MPRJ
> Message-ID: <85c89644-533c-9334-04b5-7b69c8c33...@mprj.mp.br>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Prezados,
>
> gostaria de apresentar a plataforma In Loco do Ministério Público do
> Estado do Rio de Janeiro:
>
> http://inloco.mprj.mp.br/
>
> a plataforma reúne informações sobre os mais diversos temas, com foco no
> estado do RJ.
>
> *Venho por meio deste email autorizar a importação dos dados da
> plataforma InLoco no OpenStreetMap.*
>
> Atenciosamente,
> Arlindo Pereira
> MP em Mapas - MPRJ
>
>
> -- Próxima Parte --
> Um anexo em HTML foi limpo...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-br/attachments/20180807/71a6258e/attachment-0001.html
> >
>
> --
>
> Subject: Legenda do Digest
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> --
>
> Fim da Digest Talk-br, volume 119, assunto 4
> 
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-GB] 'historic' county boundaries added to the database

[Colin Smale]

On 2018-08-08 14:17, Dave F wrote:

>> Hi
>> 
>> On 08/08/2018 12:14, Colin Smale wrote:
> 
>> If this (probably completely static) dataset is used as a baseline, at least 
>> these relations would have a verifiable source.
>> 
>> https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/boundary-line.html#Historicdownload
>> 
>> "The links above represent counties based on historic records and mapping 
>> circa 1888 and using the primary sources of the Local Government (England 
>> and Wales) Act 1888, the Local Government (Scotland) Act 1889 and the 
>> Sheriffs Act 1887. "
> 
> Those are fairly inaccurate snap shots of what thought to be accurate at that 
> just date. As Mark G pointed out it's a ridiculous notion to believe those 
> boundaries can be  extrapolated back to "Saxon times".

They would be accurate according to the source (viz. OS). 1888 is of
course nowhere near "Saxon times". If the OS-provided data were to be
used as the source of the "historic county boundaries" would that not be
grounds for a possible compromise here? 

There are plenty of examples of "former" objects in OSM - closed pubs,
railway alignments etc. They are only still there because they are
perceived to have some kind of relevance in the present day. Can a case
be made that these historic counties are still "relevant" today?  I
would like to hear smb1001's take on this.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[john whelan]

> I don’t get why highway=footway + area=yes is considered as wrong tagging
!

The problem is consistency.  If the renderers and routers don't understand
your tagging then it is less visible.

Cheerio John

On 8 August 2018 at 08:40, djakk djakk  wrote:

> I don’t get why highway=footway + area=yes is considered as wrong tagging !
>
>
> djakk
>
>
>
> Le mer. 8 août 2018 à 12:52, Tomasz Wójcik  a écrit :
>
>> As highway=footway etc. tags are set to "should not be used on areas" on
>> Wiki, and mapping them in combination with area=yes is not documented at
>> all and considered as wrong tagging by part of users, there is a key
>> "area:highway=*" (133k uses at the moment). Part of users still map footway
>> areas as a combination anyway, propably because it's rendered by default
>> style. Due to our rules, that we shouldn't have 2 active tagging schemes
>> for the same feature, so we should discuss this topic.
>>
>> I vote for area:highway=* key, because it's simpler, and it gives a
>> possibility to show also street areas with crossings in the future.
>>
>> * Wiki with specyfications of a:h=* for certain keys: https://wiki.
>> openstreetmap.org/wiki/Key:area:highway
>> * TagInfo: https://taginfo.openstreetmap.org/keys/area:highway
>> * area:highway=* visualisation: http://osmapa.pl/w/area
>>
>> ___
>> 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] Openrefine export

[Maurizio Napolitano]

On Wed, Aug 8, 2018 at 2:45 PM Cascafico Giovanni  wrote:
>
> Come segnalato da Napo, Openrefine si presta molto bene a pulire i dati, nel 
> caso specifico gli "operator" delll'anagrafica carburanti nazionale [1].
>
> Caricando il file osm [2] candidato all'import posso si può isolare e 
> manipolare errori singoli o a gruppi. Il probllema è che non so come 
> esportare nello stesso formato.
>
> Un aiutino da casa... o dalla spiaggia?

Sotto il bottone "esporta" scegli "esporta come modello"
Ti proporrà un json molto "piatto" (nel senso sequenze di chiave/valore).
Da qui potrai decidere che nomi dare alle chiavi e dove pescare, dalla
tabella, i valori.

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[djakk djakk]

I don’t get why highway=footway + area=yes is considered as wrong tagging !


djakk



Le mer. 8 août 2018 à 12:52, Tomasz Wójcik  a écrit :

> As highway=footway etc. tags are set to "should not be used on areas" on
> Wiki, and mapping them in combination with area=yes is not documented at
> all and considered as wrong tagging by part of users, there is a key
> "area:highway=*" (133k uses at the moment). Part of users still map footway
> areas as a combination anyway, propably because it's rendered by default
> style. Due to our rules, that we shouldn't have 2 active tagging schemes
> for the same feature, so we should discuss this topic.
>
> I vote for area:highway=* key, because it's simpler, and it gives a
> possibility to show also street areas with crossings in the future.
>
> * Wiki with specyfications of a:h=* for certain keys:
> https://wiki.openstreetmap.org/wiki/Key:area:highway
> * TagInfo: https://taginfo.openstreetmap.org/keys/area:highway
> * area:highway=* visualisation: http://osmapa.pl/w/area
>
> ___
> 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-it] Openrefine export

[Cascafico Giovanni]

Come segnalato da Napo, Openrefine si presta molto bene a pulire i dati,
nel caso specifico gli "operator" delll'anagrafica carburanti nazionale [1].

Caricando il file osm [2] candidato all'import posso si può isolare e
manipolare errori singoli o a gruppi. Il probllema è che non so come
esportare nello stesso formato.

Un aiutino da casa... o dalla spiaggia?




[1]
http://www.sviluppoeconomico.gov.it/images/exportCSV/anagrafica_impianti_attivi.csv
[2]
https://github.com/cascafico/OSM-ItalyFuelStations/blob/master/osm/audit-edited.osm
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] 'historic' county boundaries added to the database

[Dave F]

Hi

On 08/08/2018 12:14, Colin Smale wrote:


The OS publish boundaries for historic counties, so one could say 
these boundaries are the current boundaries for the historic counties.




To me that's an oxymoron.

If this (probably completely static) dataset is used as a baseline, at 
least these relations would have a verifiable source.


https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/boundary-line.html#Historicdownload

"The links above represent counties based on historic records and 
mapping circa 1888 and using the primary sources of the Local 
Government (England and Wales) Act 1888, the Local Government 
(Scotland) Act 1889 and the Sheriffs Act 1887. "




Those are fairly inaccurate snap shots of what thought to be accurate at 
that just date. As Mark G pointed out it's a ridiculous notion to 
believe those boundaries can be  extrapolated back to "Saxon times".


Cheers
DaveF

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

Re: [Talk-pt] Talk-pt Digest, Vol 103, Issue 2

[Marcos Oliveira]

No inicio do segmento reparei que tinham referenciado a EFFIS. [1]

[1] -
http://effis.jrc.ec.europa.eu/static/effis_current_situation/public/index.html

Nuno Caldeira  escreveu no dia quarta,
8/08/2018 à(s) 13:04:

> Bom! Só faltou mesmo a atribuição dos créditos.
>
> A quarta, 8/08/2018, 13:00,  escreveu:
>
>> Send Talk-pt mailing list submissions to
>> talk-pt@openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.openstreetmap.org/listinfo/talk-pt
>> or, via email, send a message with subject or body 'help' to
>> talk-pt-requ...@openstreetmap.org
>>
>> You can reach the person managing the list at
>> talk-pt-ow...@openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Talk-pt digest..."
>>
>>
>> Today's Topics:
>>
>>1. OpenStreetMap no Telejornal de 07/08/2018 (Marcos Oliveira)
>>
>>
>> --
>>
>> Message: 1
>> Date: Tue, 7 Aug 2018 20:13:35 +0100
>> From: Marcos Oliveira 
>> To: "Lista de discuss,o para Portugal"
>> 
>> Subject: [Talk-pt] OpenStreetMap no Telejornal de 07/08/2018
>> Message-ID:
>> <
>> caaztb0p6hrcwp3cgjozz0a4fjx-e6rk9trg28moueqtdiwr...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> https://i.imgur.com/Rb8A1Dh.png
>>
>> --
>> Um Abraço,
>> Marcos Oliveira
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-pt/attachments/20180807/e47007e9/attachment-0001.html
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>>
>> --
>>
>> End of Talk-pt Digest, Vol 103, Issue 2
>> ***
>>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [OSM-talk-fr] Projet du mois de juillet 2018 : "armoire haute tension" ?

[Julien Lepiller]

Le Wed, 8 Aug 2018 00:09:48 +0200,
François Lacombe  a écrit :

> Le 7 août 2018 à 12:55, Julien Lepiller  a écrit :
> 
> > Question similaire je pense, il s'agit là d'une plaque sur un
> > poteau :
> >
> > http://rennes.lepiller.eu/xXHZn4kj--.1.jpg  
> 
> 
> C'est une plaque de remontée aéro-souterraine (RAS)
> Ce sont des indications intéressantes pour déterminer le nom voire le
> GDO d'un poste adjacent comme tu le soulignes
> On en parle ici :
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo#Les_remont.C3.A9es_a.C3.A9ro-souterraines
> 
> Ici :
> ref=N01
> power=pole
> location:transition=yes
> material=concrete
> operator=Enedis

Merci, c'est fait ! J'en ai profité pour indiqué le matériau des autres
poteaux qui sont similaires.

> 
> 
> > https://www.openstreetmap.org/node/5804970764
> >  
> 
> Je suis très intéressé pour savoir où tu as trouvé l'exemple de
> pole:type=termination ?
> Il y a une proposition en cours de rédaction pour remplacer ces tags
> ":type".

Sur le wiki : https://wiki.openstreetmap.org/wiki/Tag:power%3Dpole

> 
> Le 7 août 2018 à 13:00, David Crochet  a
> écrit :
> 
> > Au moins tracer un chemin du point à l'autre en indiquant les mêmes
> > données de la ligne électrique avec les information de sa
> > circulation en souterraine.  
> 
> 
> Ce n'est pas évident, on ne connait pas le parcours du câble qui peut
> être tortueux, rarement en ligne droite.
> Sauf à ce qu'il y ai une trace de tranchée en surface?
> Les tags : power=cable + location=underground + cables=3 +
> operator=Enedis
> + voltage=2

Pas de trace autant que je me souvienne. Je ne vais pas pouvoir
vérifier, je suis dans le train pour rentrer en Bretagne.

Est-ce que je peux indiquer voltage=2 sur la ligne aérienne ?

D'ailleurs, j'indique toujours voltage=2;400 sur les postes, comme
l'indique osmose. Est-ce la bonne chose à faire, et comment savoir sur
le terrain quelle est la bonne valeur ?

> 
> 
> Merci pour ces cas qui nous permettent d'améliorer ensemble la doc :)
> Bonne soirée
> 
> François


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

Re: [OSM-talk-fr] Fusionner ways en une seule track?

[Shohreh]

Merci beaucoup. Je vais essayer.



--
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-GB] 'historic' county boundaries added to the database

[Dave F]

On 08/08/2018 12:05, Lester Caine wrote:

On 08/08/18 10:56, Dave F wrote:


On 08/08/2018 09:54, Lester Caine wrote:
we are now in a situation where much accurately mapped material is 
simply dumped when there is a change to the current situation.

1. it's not dumped, it's still in the database as a historic version.
2. Changes almost always increase the accuracy & detail of the database.


Going back through the change logs is not the easiest process? 


Overpass API QL language offers means to do it using version() & a 
couple of other commands


Isolating deletions that are due to historic changes rather than 
simple factual corrections also muddies the water. But making the link 
to OHM more organised would allow current valid data to be archived 
properly?


It's possible to upload using JOSM, I believe (haven't used it), but I 
agree, a more open gateway for transferring would be useful.




The 'delete' process should be handled in a manor more sensitive to 
the hard work that has gone before!


the vast majority of the material making up the historic data such 
as boundaries IS the same as the current 'live' data.


I'm unsure that's true, but if it were, why duplicate?


That was always my argument AGAINST OHM ... since much of the data 
making up boundaries has not changed, having to duplicate that 
information over to OHM, and then decide where material is current or 
historic means that IDEALLY OHM is a complete copy of the OSM 
database, but with the historic material easier to find than via 
change sets ... why not just manage a single database? People who 
don't want access to historic material simply ignore data which has 
'expired' via end_date.


How often do you believe people will actually want historic data? 
Organizations archive for a reason. Consider your house, how things you 
don't use will get shoved to the back of the cupboard/shed.
I live in a Roman city, the editors struggle to display current data. 
Imagine what it would be like if *everything* was shown back to the days 
of Emperor Nero.


Cheers
DaveF

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

Re: [Talk-it] BRouter Suspect Scanner

[Cascafico Giovanni]

>
> 2018-08-08 12:20 GMT+02:00 Cascafico Giovanni :
>
>> Il problema con questo genere di QA sono i tempi di riscontro.
>>
> Concordo che i tempi di aggiornamento sono un po' lunghi. Però piuttosto
> che niente, meglio piuttosto ;-)
>
>
Avevo fatto tempo fa un bot telegram [1] che generava al volo una zona
ruotabile. Non è molto stabile, ma credo che l'idea possa magari essere
sviluppata da un programmatore vero ;-) magari con un interfaccia web anche
per la query, invece del poco pratico bot.

In sintesi, si preleva con overpass solo le way e le relazioni di
restrizione in una piccola bbox; poi si compilano in un grafo per routino
[2]. Gli script che ora gestiscono il bot sono in github [3]


[1] https://t.me/RoutinoBot
[2] http://www.routino.org/
[3] https://github.com/cascafico/RoutinoPatcher
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Una nuova frontiera nello spam?

[Andrea Musuruane]

https://www.openstreetmap.org/changeset/61449689

Ciao,

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Colin Smale]

The OS publish boundaries for historic counties, so one could say these
boundaries are the current boundaries for the historic counties. If this
(probably completely static) dataset is used as a baseline, at least
these relations would have a verifiable source. 

https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/boundary-line.html#Historicdownload


"The links above represent counties based on historic records and
mapping circa 1888 and using the primary sources of the Local Government
(England and Wales) Act 1888, the Local Government (Scotland) Act 1889
and the Sheriffs Act 1887. "

On 2018-08-08 13:05, Lester Caine wrote:

> On 08/08/18 10:56, Dave F wrote: 
> On 08/08/2018 09:54, Lester Caine wrote: we are now in a situation where much 
> accurately mapped material is simply dumped when there is a change to the 
> current situation. 1. it's not dumped, it's still in the database as a 
> historic version.
> 2. Changes almost always increase the accuracy & detail of the database.

Going back through the change logs is not the easiest process? Isolating
deletions that are due to historic changes rather than simple factual
corrections also muddies the water. But making the link to OHM more
organised would allow current valid data to be archived properly?

>> The 'delete' process should be handled in a manor more sensitive to the hard 
>> work that has gone before!
>> 
>> the vast majority of the material making up the historic data such as 
>> boundaries IS the same as the current 'live' data.
> 
> I'm unsure that's true, but if it were, why duplicate?

That was always my argument AGAINST OHM ... since much of the data
making up boundaries has not changed, having to duplicate that
information over to OHM, and then decide where material is current or
historic means that IDEALLY OHM is a complete copy of the OSM database,
but with the historic material easier to find than via change sets ...
why not just manage a single database? People who don't want access to
historic material simply ignore data which has 'expired' via end_date.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 08/08/18 11:49, David Woolley wrote:
I think people are overlooking the original use case for suppressing C 
references, which was that they confused satellite navigator users. As I 
pointed out before, this is really an attribute of the particular turn 
onto the road, not the road itself.  The fact that a road (A, B, or C) 
may have its reference displayed somewhere along it is not going to help 
if someone approaching the turn cannot easily see that reference.


That is little different to being told to 'turn right into "this" road' 
where most of the time one can't see a road name. It is perhaps a matter 
of identifying just which turns have a visible sign and which do not, 
and that can often apply even to A roads? But even if there is no 
signage, giving some road details is better than a simple 'turn right'? 
Many of main link roads around here don't have names or numbers 
displayed, but one still use them to avoid several miles of 'detour' via 
primary roads because the sat nav does no accept them as a 'fast route'. 
OSMAnd is a sod for that problem :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 10:56, Dave F wrote:


On 08/08/2018 09:54, Lester Caine wrote:
we are now in a situation where much accurately mapped material is 
simply dumped when there is a change to the current situation.

1. it's not dumped, it's still in the database as a historic version.
2. Changes almost always increase the accuracy & detail of the database.


Going back through the change logs is not the easiest process? Isolating 
deletions that are due to historic changes rather than simple factual 
corrections also muddies the water. But making the link to OHM more 
organised would allow current valid data to be archived properly?


The 'delete' process should be handled in a manor more sensitive to 
the hard work that has gone before!


the vast majority of the material making up the historic data such as 
boundaries IS the same as the current 'live' data.


I'm unsure that's true, but if it were, why duplicate?


That was always my argument AGAINST OHM ... since much of the data 
making up boundaries has not changed, having to duplicate that 
information over to OHM, and then decide where material is current or 
historic means that IDEALLY OHM is a complete copy of the OSM database, 
but with the historic material easier to find than via change sets ... 
why not just manage a single database? People who don't want access to 
historic material simply ignore data which has 'expired' via end_date.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Andy Townsend]

On 08/08/18 10:34, Dave F wrote:



On 08/08/2018 08:30, Andy Townsend wrote:
 The tags "highway_authority_ref" "admin_ref" and "official_ref" are 
assumed to be unsigned.


One of the items on my 'things to do' list was to search for & 
amalgamate any 'this road is signed' tags.




The last time I looked there were three ways of tagging these - 
"name:signed=no", "unsigned=yes" and "unsigned=true".


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L227

The first is unambiguous, the others perhaps not so much.  If you can 
find any others I'll happily include a test for those too.


Best Regards,

Andy


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

[OSM-talk] highway=* + area=yes vs area:highway=*

[Tomasz Wójcik]

As highway=footway etc. tags are set to "should not be used on areas" on 
Wiki, and mapping them in combination with area=yes is not documented at 
all and considered as wrong tagging by part of users, there is a key 
"area:highway=*" (133k uses at the moment). Part of users still map 
footway areas as a combination anyway, propably because it's rendered by 
default style. Due to our rules, that we shouldn't have 2 active tagging 
schemes for the same feature, so we should discuss this topic.


I vote for area:highway=* key, because it's simpler, and it gives a 
possibility to show also street areas with crossings in the future.


* Wiki with specyfications of a:h=* for certain keys: 
https://wiki.openstreetmap.org/wiki/Key:area:highway

* TagInfo: https://taginfo.openstreetmap.org/keys/area:highway
* area:highway=* visualisation: http://osmapa.pl/w/area
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] 'C' class roads references.

[David Woolley]

I think people are overlooking the original use case for suppressing C 
references, which was that they confused satellite navigator users. As I 
pointed out before, this is really an attribute of the particular turn 
onto the road, not the road itself.  The fact that a road (A, B, or C) 
may have its reference displayed somewhere along it is not going to help 
if someone approaching the turn cannot easily see that reference.


On 08/08/18 10:34, Dave F wrote:



On 08/08/2018 08:30, Andy Townsend wrote:
 The tags "highway_authority_ref" "admin_ref" and "official_ref" are 
assumed to be unsigned.


One of the items on my 'things to do' list was to search for & 
amalgamate any 'this road is signed' tags.


DaveF

___
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: [Talk-it] BRouter Suspect Scanner

[Andrea Musuruane]

Ciao,

2018-08-08 12:20 GMT+02:00 Cascafico Giovanni :

> Il problema con questo genere di QA sono i tempi di riscontro. Ho viste un
> paio di anomalie e non trovo il problema. Poi ho provato l'apertura con
> remote control JOSM e non mi funziona (Error: 404 Not Found).
>

Ho già segnalato il problema con il remote control di JOSM.


> Prendo per esempio questo [1] svincolo: il Brouter non mi fa proseguire,
> mentre il plugin routing di JOSM si. Ora potrebbe essere intervenuto
> qualche mappatore a sistemare 6-7 giorni fa, ma per capire che era successo
> proprio questo, ho dovuto cercare nella history di almeno quattro oggetti.
> Mi sembra un po ' laborioso: ci sono scorciatoie?
>

L'ho sistemato io poco fa. In tutta l'area le relazioni straight_on erano
errate.

Concordo che i tempi di aggiornamento sono un po' lunghi. Però piuttosto
che niente, meglio piuttosto ;-)

Ciao,

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

Re: [Talk-it] BRouter Suspect Scanner

[Cascafico Giovanni]

Il problema con questo genere di QA sono i tempi di riscontro. Ho viste un
paio di anomalie e non trovo il problema. Poi ho provato l'apertura con
remote control JOSM e non mi funziona (Error: 404 Not Found).

Prendo per esempio questo [1] svincolo: il Brouter non mi fa proseguire,
mentre il plugin routing di JOSM si. Ora potrebbe essere intervenuto
qualche mappatore a sistemare 6-7 giorni fa, ma per capire che era successo
proprio questo, ho dovuto cercare nella history di almeno quattro oggetti.
Mi sembra un po ' laborioso: ci sono scorciatoie?


[1]
http://brouter.de/brouter-web/#zoom=17=44.47613=7.68917=OpenStreetMap=7.692313,44.476019|7.69036,44.47729=car-eco==0=geojson

Il giorno 8 agosto 2018 11:49, Andrea Musuruane  ha
scritto:

> Nell'About ho trovato "Data: based on OpenStreetMap. It is usually updated
> once a week when a new Planet file is available, see dates of data files. "
>
> Ciao,
>
> Andrea
>
>
> 2018-08-08 11:37 GMT+02:00 Cascafico Giovanni :
>
>> Approssimativamente, quanto tempo prende l'aggiornamento del grafo su
>> brouter.de?
>>
>> Il giorno 8 agosto 2018 11:09, Andrea Musuruane  ha
>> scritto:
>>
>>> Ciao a tutti,
>>> all'ultimo State of the Map, Arndt Brenschede ha fatto una
>>> presentazione su "Energy efficient routing with OSM":
>>> https://2018.stateofthemap.org/2018/T101-Energy_efficient_ro
>>> uting_with_OSM/
>>>
>>> La registrazione è disponibile qui:
>>> https://youtu.be/hUkE_fHEoZ8?t=11366
>>>
>>> Arndt ha sviluppato un software di routing chiamato Brouter:
>>> http://brouter.de/brouter/
>>>
>>> Durante la presentazione, ha anche illustrato il tool BRouter Suspect
>>> Scanner che serve ad individuare problemi di routing:
>>> http://brouter.de:443/brouter/suspects
>>>
>>> Il readme che illustra il funzionamento è disponibile qui:
>>> http://brouter.de/brouter/suspect_scanning_readme.txt
>>>
>>> Gentilmente, su mia richiesta, Arndt ha recentemente aggiunto anche
>>> l'Italia tra i paesi supportati.
>>>
>>> Purtroppo di problemi di routing ce ne sono tantissimi, quindi consiglio
>>> a tutti i mapper di buona volontà di mettersi al lavoro. Gli utenti dei
>>> software di navigazione vi ringrazieranno :-)
>>>
>>> Ciao,
>>>
>>> Andrea
>>>
>>>
>>> ___
>>> 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-GB] 'historic' county boundaries added to the database

[Mark Goodge]

On 07/08/2018 20:48, Dave F wrote:

Hi

User smb1001 is currently adding county boundary relations with 
boundary=historic through out the UK:

http://overpass-turbo.eu/s/ASf (May take a while to run)

Changeset discussion:
https://www.openstreetmap.org/changeset/61410203

 From the historic wiki page
"historic objects should not be mapped as it is outside of scope of OSM"

Frankly I don't buy his comments. The problem is where to stop? Do we 
have ever iteration of every boundary change since time immemorial? Then 
what about buildings, roads, or coastline changes etc? The database 
would become unmanageable for editors (it already is if zoomed out too 
far).


I agree that "historic" boundaries don't belong in OSM. They have value 
for historic researchers, but, as you say, that's not what OSM is about.


It's also flat out incorrect to say that historic boundaries are 
"immutable". Although it is true that there were massive changes in the 
1970s and a lot more since then, the idea that the historic (or 
"traditional") counties were stable throughout history is just 
myth-making. A lot of what people think of as the historic county 
boundaries are, in fact, a Victorian creation. And even they didn't 
leave them alone!


I do think, though, that there's a case for including the current 
ceremonial and preserved county boundaries. These have a defined and 
relevant meaning here and now, even if it's a less common one than 
administrative boundaries such as counties, districts and parishes. 
Maybe the people adding historic boundaries to OSM could be nudged in 
that direction instead.


Mark

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Dave F]

Hi

On 08/08/2018 09:54, Lester Caine wrote:
we are now in a situation where much accurately mapped material is 
simply dumped when there is a change to the current situation.

1. it's not dumped, it's still in the database as a historic version.
2. Changes almost always increase the accuracy & detail of the database.

The 'delete' process should be handled in a manor more sensitive to 
the hard work that has gone before!


the vast majority of the material making up the historic data such as 
boundaries IS the same as the current 'live' data.


I'm unsure that's true, but if it were, why duplicate?

Cheers
DaveF.

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

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Musuruane]

Nell'About ho trovato "Data: based on OpenStreetMap. It is usually updated
once a week when a new Planet file is available, see dates of data files. "

Ciao,

Andrea


2018-08-08 11:37 GMT+02:00 Cascafico Giovanni :

> Approssimativamente, quanto tempo prende l'aggiornamento del grafo su
> brouter.de?
>
> Il giorno 8 agosto 2018 11:09, Andrea Musuruane  ha
> scritto:
>
>> Ciao a tutti,
>> all'ultimo State of the Map, Arndt Brenschede ha fatto una
>> presentazione su "Energy efficient routing with OSM":
>> https://2018.stateofthemap.org/2018/T101-Energy_efficient_
>> routing_with_OSM/
>>
>> La registrazione è disponibile qui:
>> https://youtu.be/hUkE_fHEoZ8?t=11366
>>
>> Arndt ha sviluppato un software di routing chiamato Brouter:
>> http://brouter.de/brouter/
>>
>> Durante la presentazione, ha anche illustrato il tool BRouter Suspect
>> Scanner che serve ad individuare problemi di routing:
>> http://brouter.de:443/brouter/suspects
>>
>> Il readme che illustra il funzionamento è disponibile qui:
>> http://brouter.de/brouter/suspect_scanning_readme.txt
>>
>> Gentilmente, su mia richiesta, Arndt ha recentemente aggiunto anche
>> l'Italia tra i paesi supportati.
>>
>> Purtroppo di problemi di routing ce ne sono tantissimi, quindi consiglio
>> a tutti i mapper di buona volontà di mettersi al lavoro. Gli utenti dei
>> software di navigazione vi ringrazieranno :-)
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> ___
>> 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] BRouter Suspect Scanner

[Cascafico Giovanni]

Approssimativamente, quanto tempo prende l'aggiornamento del grafo su
brouter.de?

Il giorno 8 agosto 2018 11:09, Andrea Musuruane  ha
scritto:

> Ciao a tutti,
> all'ultimo State of the Map, Arndt Brenschede ha fatto una
> presentazione su "Energy efficient routing with OSM":
> https://2018.stateofthemap.org/2018/T101-Energy_
> efficient_routing_with_OSM/
>
> La registrazione è disponibile qui:
> https://youtu.be/hUkE_fHEoZ8?t=11366
>
> Arndt ha sviluppato un software di routing chiamato Brouter:
> http://brouter.de/brouter/
>
> Durante la presentazione, ha anche illustrato il tool BRouter Suspect
> Scanner che serve ad individuare problemi di routing:
> http://brouter.de:443/brouter/suspects
>
> Il readme che illustra il funzionamento è disponibile qui:
> http://brouter.de/brouter/suspect_scanning_readme.txt
>
> Gentilmente, su mia richiesta, Arndt ha recentemente aggiunto anche
> l'Italia tra i paesi supportati.
>
> Purtroppo di problemi di routing ce ne sono tantissimi, quindi consiglio a
> tutti i mapper di buona volontà di mettersi al lavoro. Gli utenti dei
> software di navigazione vi ringrazieranno :-)
>
> Ciao,
>
> Andrea
>
>
> ___
> 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-es] Caminos con autorización

[Javier Sánchez Portero]

Hola.

En la lista internacional tagging se ha preguntado recientemente [1] por el
valor adecuado para caminos/zonas en los que es necesario solicitar un
permiso para acceder para practicar alguna actividad en la naturaleza
(senderismo, ciclismo, caza, pesca). No me refiero a una licencia genérica
sino a un permiso para una fecha concreta, solicitado a una administración
(generalmente), que se concede por criterios de carga del medio u otros.
Cualquiera puede solicitarlo y puede implicar un pago o no.

Se está concluyendo que lo mejor sería reactivar una propuesta estancada en
su momento [2]. Si alguien tiene interés en el tema paso los enlaces y
sería bueno añadir ejemplos a la lista de la propuesta si los conocen.

Saludos, Javier.

[1] https://lists.openstreetmap.org/pipermail/tagging/2018-July/038032.html
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/access%3Dpermit
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-it] BRouter Suspect Scanner

[Andrea Musuruane]

Ciao a tutti,
all'ultimo State of the Map, Arndt Brenschede ha fatto una
presentazione su "Energy efficient routing with OSM":
https://2018.stateofthemap.org/2018/T101-Energy_efficient_routing_with_OSM/

La registrazione è disponibile qui:
https://youtu.be/hUkE_fHEoZ8?t=11366

Arndt ha sviluppato un software di routing chiamato Brouter:
http://brouter.de/brouter/

Durante la presentazione, ha anche illustrato il tool BRouter Suspect
Scanner che serve ad individuare problemi di routing:
http://brouter.de:443/brouter/suspects

Il readme che illustra il funzionamento è disponibile qui:
http://brouter.de/brouter/suspect_scanning_readme.txt

Gentilmente, su mia richiesta, Arndt ha recentemente aggiunto anche
l'Italia tra i paesi supportati.

Purtroppo di problemi di routing ce ne sono tantissimi, quindi consiglio a
tutti i mapper di buona volontà di mettersi al lavoro. Gli utenti dei
software di navigazione vi ringrazieranno :-)

Ciao,

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[David Woolley]

On 08/08/18 09:54, Lester Caine wrote:
They should be moved to OHM but then ANY information that is superseded 
should be automatically archived to SOMETHING since we are now in a 
situation where much accurately mapped material is simply dumped when 
there is a change to the current situation. The 'delete' process should 
be handled in a manor more sensitive to the hard work that has gone before!




Although it can be fiddly to access, the data is not lost.  All you need 
is the changeset number of the deletion to be able to access the deleted 
data and its complete revision history.


A revertion is not a special operation in the database, so would just be 
recorded as a changeset deleting the objects reflecting the historic 
boundary.


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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 07/08/18 20:48, Dave F wrote:


User smb1001 is currently adding county boundary relations with 
boundary=historic through out the UK:

http://overpass-turbo.eu/s/ASf (May take a while to run)

Changeset discussion:
https://www.openstreetmap.org/changeset/61410203

 From the historic wiki page
"historic objects should not be mapped as it is outside of scope of OSM"

Frankly I don't buy his comments. The problem is where to stop? Do we 
have ever iteration of every boundary change since time immemorial? Then 
what about buildings, roads, or coastline changes etc? The database 
would become unmanageable for editors (it already is if zoomed out too 
far).


I think these edits should be revoked.


They should be moved to OHM but then ANY information that is superseded 
should be automatically archived to SOMETHING since we are now in a 
situation where much accurately mapped material is simply dumped when 
there is a change to the current situation. The 'delete' process should 
be handled in a manor more sensitive to the hard work that has gone before!


I have always disagreed that 'historic changes have no place in the 
database', since the vast majority of the material making up the 
historic data such as boundaries IS the same as the current 'live' data. 
Simply not downloading data that has a prior end date does not make 
anything 'unmanageable', in fact it makes life a hell of a lot easier 
since one can simply tag a section of the boundary as 'end_date=xxx' and 
add a new section with the boundary change as 'start_date=xxx'. The ONLY 
question is what happens to the data once it has an end date ... which 
may be some time in the future ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-in] tasks.openstreetmap.in is down

[Craig Dsouza]

Yep, I'm having the same issue at login

On Wed, Aug 1, 2018 at 6:25 PM Nikhil VJ  wrote:

> Hello,
>
> Apologies if this is a repeat post.. I'm not seeing these mailing lists
> often.
>
> The India HOT Tasking Manager site http://tasks.openstreetmap.in is not
> working when we try to login. Getting a generic error message
>
> > "The server encountered an internal error or misconfiguration and was
> unable to complete your request."
>
> And at some places, advertisement popups are spawning, there might be some
> malware scripts at play.
>
> A fellow mapper who had been participating in our project
>  there just wrote to me about
> it.
>
> Other tasking manager sites I checked are up and running properly.
>
>
> --
> Cheers,
> Nikhil VJ
> +91-966-583-1250
> Pune, India
> Website 
> DataMeet Pune chapter 
> Self-designed learner at Swaraj University <
> http://www.swarajuniversity.org>
> Payment / Contribute 
>


-- 

*Independent Researcher - Water Resources Management*
*Open Water Data Project*
Web App: https://water-data-web-app.appspot.com/
Website: https://datameet-pune.github.io/open-water-data/
*My Blog*: unravellingindia.in
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 08/08/18 08:30, Andy Townsend wrote:
There are combinations that aren't handled perfectly (especially where 
roads have a mixture of different refs) and I'll look at some of these 
edge cases later.  Hopefully though as things stand it's useful to 
people who really want to see these "official" refs.


I think this is part of the 'UK' problem. While some reference numbers 
are not displayed 'on the ground', increasingly they ARE being used in 
official announcements such as accident reports, road closures, planning 
applications and the like so that the relevant authorities know they are 
talking about the same stretch of road, but that does not help us 'mere 
mortals' unless someone actually publishes a map to show the situation 
on the ground. That OSM IS in a position to fill this hole where often 
even the official maps do not because OS does not provide a rendering 
using them is just another plus for OSM. But I have no problem accepting 
that this should be on a UK specific map rather than something dumbed 
down for the whole world ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk-fr] arrêt de bus du réseau Mat

[Jo]

Ici en Belgique, c'est vrai que ce sont les communes qui construisent et
maintiennent les arrêts et les abribus et encore un autre opérateur qui y
met de la pub.

Mais c'est tout de même l'opérateur qui y met un 'drapeau' et les horaires
et qui les maintient à jour. Quand moi je parle d'un arrêt je parle de
quelque chose plus ou moins abstrait; un 'contrat' entre opérateur de
transports en commun et les passager que à cet endroit à certains moments
il y a des véhicules qui passent et qui prennent des voyageurs pour les
porter autre part. Cette chose 'abstraite' c'est ce que représentent les
noeuds highway=bus_stop/railway=tram_stop. Et si on le voit comme cela, il
me semble normal de dire que tel ou tel arrêt est déservi par tel et/ou tel
opérateur ou fait partie de tel ou tel réseau.

L'infrastructure comme les quais, les abris, les poubelles, etc on pourrait
dire que ce sont les communes qui sont l'opérateur, mais on ne l'ajoute pas
sur ces objets-là, car ça a vraiment peu d'importance.

Ajouter operator et network sur les arrêts peut servir pour valider qu'ils
appartiennent tous à des relations d'opérateurs/réseaux correspondants. Je
ne pense pas que cela se fait en ce moment, mais c'est avec cette idée que
je les avais ajoutés sur tous les arrêts, du moins en Belgique.

Le même pour route_ref sur les arrêts. C'est facile à noter quand on est à
coté de l'arrêt, mais après aussi ça continue de servir pour vérifier si ça
correspond aux refs des relations route. PT_Assistant le fait dès à présent.

Polyglot

Op wo 8 aug. 2018 om 09:43 schreef Philippe Verdy :

> En l'occurence l'exploitant d'une ligne n'est qu'un usager de
> l'infrastructure utilisée! les arrêts, plateformes ont un opérateur
> indépendant, la commune ou plus souvent l'EPCI qui est en charge de
> l'exclusivité de la gestion des transports sur son territoire, parfois un
> opérateur privé (centre commerciaux, hopitaux, gares routières ou
> ferroviaires, ou un service public comme la CPAM ou la CAF, ou encore une
> grosse entreprise...).
> Et c'est lui qui confie cette autorisation à un opérateur d'exploitation
> de l'équipement (parfois plusieurs selon le type d'équipements : abris,
> toilettes, poubelles, ascenseurs, publicité, automates) qui n'est pas
> forcément celui qui exploite les lignes concernées : les exploitants de
> lignes demandent à l'exploitant local de l'infrastructure les autorisations
> pour utiliser/équiper les arrêts concernés.
>
> Bref l'opérateur d'un arrêt, d'une plateforme, n'est très souvent PAS
> celui de "la" ligne ou du réseau de lignes (même quand il n'y a qu'une
> seule ligne d'un seul opérateur réseau à l'utiliser) !
>
> Dans le cas des lignes départementales (ou régionales), la plateforme
> d'arrêt n'est que très rarement de son ressort (même s'il y a un panneau et
> l'arrêt n'est pas desservi du tout par une ligne du réseau de l'EPCI),
> c'est presque toujours l'opérateur de gestion d'infrastructure de l'EPCI ou
> de la commune qui s'en charge et communique avec les opérateurs de lignes.
> Il n'y a aucune raison donc de mettre plusieurs opérateurs par arrêt mais
> aucune raison de supposer que c'est celui de la ligne qui y passe (et
> impossible de déduire quoi que ce soit de ces relations de lignes)
>
> Si je prends l'exemple des arrêts de bus à Rennes, ils sont presque tous
> du ressort de la STAR, qu'ils soient utilisés par les lignes de la STAR ou
> les lignes départementales (en cours de restructuration) ou régionales
> (TER). Les lignes départementales et régionales n'utilisent QUE les arrêts
> de la STAR (y compris la gare routière qui dépend d'un collectif regroupant
> la STAR, la commune de Rennes, et la SNCF, mais la STAR en assure la
> gestion pour tous les autres exploitants). Quand la STAR va équiper un
> arrêt, il sera dans un temps utilisé par une ligne d'un opérateur
> quelconque mais ensuite il pourra être utilisé par d'autres lignes d'autres
> opérateurs ou par la STAR, selon ce qu'en décidera Rennes Métropole pour
> l'ouverture de lignes ou pas, ou selon les demandes faites à la STAR par
> les usagers et les enquêtes publiques). Ce n'est pas les autres opérateurs
> qui se chargent de l'éuipement, ils ne vont apporter qu'une signalisation
> légère à afficher (plans de ligne). C'est bien souvent la STAR qui va aussi
> marquer les arrêts pour lui (numéro de ligne) et faire réaliser les travaux
> (bateaux, marquages au sol de la zone d'arrêt), la commune se chargeant
> elle de la signalisation périphérique sur la voie pour les autres usagers
> (sauf sur les routes départementales ou nationales) tels que les priorités
> ou panneaux de voies réservées aux transports.
>
>
> Le 5 août 2018 à 10:41, marc marc  a écrit :
>
>> Le 05. 08. 18 à 07:57, mga_geo a écrit :
>> > Ayant ajouté l'attribut 'network' aux arrêts, Osmose les détecte tous,
>> > par exemple http://osmose.openstreetmap.fr/fr/error/19213745550
>>
>> c'est controversé.
>> l'endroit le + adapté est bien la relation comme le suggère 

[Talk-GB] BHF et al Creating AED Location Database (news item)

[David Woolley]

In the 8 am radio 4 news today there was an item about the British Heart 
Foundation creating a database of AED locations because these are often 
not known to people.  Although not the BBC, this is another article 
based on the same news release: 



It mentions the NHS, Microsoft and the BHF, so I wonder if this is being 
done in ignorance of OSM attempts to collect this information.


The first line data consumer is ambulance controllers, so that they can 
direct 999 callers to the devices.  (I'd tend to agree that OSM 
providing this information directly to the general public is not going 
to sufficiently effective, as not enough people will know how to access 
the information and have mobile devices set up to do so quickly in an 
emergency.)


There is a contact email for the project, in the press release, 
n...@bhf.org.uk.


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

Re: [OSM-talk-fr] arrêt de bus du réseau Mat

[Philippe Verdy]

En l'occurence l'exploitant d'une ligne n'est qu'un usager de
l'infrastructure utilisée! les arrêts, plateformes ont un opérateur
indépendant, la commune ou plus souvent l'EPCI qui est en charge de
l'exclusivité de la gestion des transports sur son territoire, parfois un
opérateur privé (centre commerciaux, hopitaux, gares routières ou
ferroviaires, ou un service public comme la CPAM ou la CAF, ou encore une
grosse entreprise...).
Et c'est lui qui confie cette autorisation à un opérateur d'exploitation de
l'équipement (parfois plusieurs selon le type d'équipements : abris,
toilettes, poubelles, ascenseurs, publicité, automates) qui n'est pas
forcément celui qui exploite les lignes concernées : les exploitants de
lignes demandent à l'exploitant local de l'infrastructure les autorisations
pour utiliser/équiper les arrêts concernés.

Bref l'opérateur d'un arrêt, d'une plateforme, n'est très souvent PAS celui
de "la" ligne ou du réseau de lignes (même quand il n'y a qu'une seule
ligne d'un seul opérateur réseau à l'utiliser) !

Dans le cas des lignes départementales (ou régionales), la plateforme
d'arrêt n'est que très rarement de son ressort (même s'il y a un panneau et
l'arrêt n'est pas desservi du tout par une ligne du réseau de l'EPCI),
c'est presque toujours l'opérateur de gestion d'infrastructure de l'EPCI ou
de la commune qui s'en charge et communique avec les opérateurs de lignes.
Il n'y a aucune raison donc de mettre plusieurs opérateurs par arrêt mais
aucune raison de supposer que c'est celui de la ligne qui y passe (et
impossible de déduire quoi que ce soit de ces relations de lignes)

Si je prends l'exemple des arrêts de bus à Rennes, ils sont presque tous du
ressort de la STAR, qu'ils soient utilisés par les lignes de la STAR ou les
lignes départementales (en cours de restructuration) ou régionales (TER).
Les lignes départementales et régionales n'utilisent QUE les arrêts de la
STAR (y compris la gare routière qui dépend d'un collectif regroupant la
STAR, la commune de Rennes, et la SNCF, mais la STAR en assure la gestion
pour tous les autres exploitants). Quand la STAR va équiper un arrêt, il
sera dans un temps utilisé par une ligne d'un opérateur quelconque mais
ensuite il pourra être utilisé par d'autres lignes d'autres opérateurs ou
par la STAR, selon ce qu'en décidera Rennes Métropole pour l'ouverture de
lignes ou pas, ou selon les demandes faites à la STAR par les usagers et
les enquêtes publiques). Ce n'est pas les autres opérateurs qui se chargent
de l'éuipement, ils ne vont apporter qu'une signalisation légère à afficher
(plans de ligne). C'est bien souvent la STAR qui va aussi marquer les
arrêts pour lui (numéro de ligne) et faire réaliser les travaux (bateaux,
marquages au sol de la zone d'arrêt), la commune se chargeant elle de la
signalisation périphérique sur la voie pour les autres usagers (sauf sur
les routes départementales ou nationales) tels que les priorités ou
panneaux de voies réservées aux transports.


Le 5 août 2018 à 10:41, marc marc  a écrit :

> Le 05. 08. 18 à 07:57, mga_geo a écrit :
> > Ayant ajouté l'attribut 'network' aux arrêts, Osmose les détecte tous,
> > par exemple http://osmose.openstreetmap.fr/fr/error/19213745550
>
> c'est controversé.
> l'endroit le + adapté est bien la relation comme le suggère osmose.
> certains dupliquent l'info de la relation sur tous les arrêts de la
> relation, y compris avec le tag operator, y compris au point d'avoir
> plusieurs tags operator sur un arrêt, y compris si l'operateur de
> l'abribus n'est pas le même que celui de la ligne de bus.
> Pour ma part au lieu de mettre une information dupliquée et souvent
> fausse sur l'arrêt, je ne la met que sur la relation.
> Mais certains te soutiendront le contraire
>
> > En l'absence de stop_area, il me semblait que cet attribut était
> recommandé
> > https://wiki.openstreetmap.org/wiki/Tag:public_transport=platform
>
> cela mériterait en effet amélioration
> ___
> 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-GB] 'C' class roads references.

[Andy Townsend]

For completeness, I have updated https://map.atownsend.org.uk to show 
unsigned road names in brackets and unsigned refs in brackets at the end 
of the name.  The tags "highway_authority_ref" "admin_ref" and 
"official_ref" are assumed to be unsigned.


Examples:

https://www.openstreetmap.org/way/135465545
https://map.atownsend.org.uk/maps/map/map.html#zoom=18=54.099587=-1.0061
(neither the name nor the highway_authority_ref here appear on the road)

https://www.openstreetmap.org/way/148638397
https://map.atownsend.org.uk/maps/map/map.html#zoom=19=52.90617=-1.450913
(the name is signed but the ref isn't)

https://www.openstreetmap.org/way/89182833
https://map.atownsend.org.uk/maps/map/map.html#zoom=20=54.2394176=-2.857967
(no name, and the admin_ref is presumably unsigned)

https://www.openstreetmap.org/way/55579162
https://map.atownsend.org.uk/maps/map/map.html#zoom=21=52.6307176=1.3776586
(name but different ref and highway_authority_ref)


There are combinations that aren't handled perfectly (especially where 
roads have a mixture of different refs) and I'll look at some of these 
edge cases later.  Hopefully though as things stand it's useful to 
people who really want to see these "official" refs.


Best Regards,

Andy


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

Re: [talk-ph] Advanced imagery alignment with Imagery Offsets DB

[grab osm]

Hello All,

In further continuation to our earlier message on map enhancements efforts
in Metro Manila, we wanted to inform local mappers and community that we
started the city this morning.
We also used the offset distance as appropriate for the change sets uploaded

Here are the change sets we worked on since morning today mapped with
respective offset distances used.  Will be of great help if anyone from the
team can have a quick review of a couple of them and confirm we are in the
right track with reference to using the offsets.  Thanks in advance

Changeset Number Offset Distance
61452499 1.2 m
61453192 1.2 m
61453920 1.2 m
61454492 1.2 m
61452621 87cm
61453227 87cm
61453842 87cm
61454488 87cm
61454136 2.3 m
61454560 1.1 m
61455283 1.1 m
Thanks
Lavanya
Grab Team



On Mon, Aug 6, 2018 at 12:17 PM, grab osm  wrote:

> Hello All,
>
> As we got to know about the attachment file size limitations off-late ,
> and as suggested by Eugene, we have referenced the doc in our issue
> created in git hub project page.
> Here is the link - https://github.com/GRABOSM/Grab-Data/issues/19
>
> Thanks
> Lavanya
> Grab Team
>
> On Mon, Aug 6, 2018 at 8:51 AM, grab osm  wrote:
>
>> Good Morning All,
>>
>> Firstly, we would like to sincerly thank Erwin and Rally for the detailed
>> explanation on how to use offset database.
>>
>> A quick clarification of the objects we mentioned in our github issue
>> page..
>> Before we started to work on Metro Manila, a note was posted in PH
>> facebook page in the intent to get help from local community on any specifc
>> policies to be followed, offset distance to be maintained etc.
>> Alvin from the community made a point that there was a significant
>> contribution made by Kaart team in the same area, so, we wanted to evaualte
>> the city and understand if we want to continue working on Metro Manila or
>> not.
>> Two categories of objects were mentioned in the page -
>> - missing roads - way id or node id mentioned here are the ids of roads
>> nearby to the missing roads.
>> - classification gaps - example objects with incorrect classifications.
>>
>> Hence these objects posted in our github page are only examples of
>> missing roads and classification gaps we found in the sample areas we
>> investigated and does not comprise the entire work we intend to do in the
>> city.
>>
>> As suggested by Erwin, to further clarify what do we mean by
>> classification gaps we tried to explain a handful of instances so that we
>> can explain our project to the community better.
>>
>> Here is the document with examples.
>>
>> Local mappers have been of great help and support and we will ensure to
>> continue producing high quality maps within our scope.
>>
>> Thanks
>> Lavanya
>> Grab Team
>>
>>
>>
>> On Fri, Aug 3, 2018, 08:33 Erwin Olario  wrote:
>>
>>> Earlier this week, the OSM data team of Grab posted an email [0]about
>>> their plan to address issues [1] they found in NCR, which has led to a
>>> discussion about the Imagery Offsets Database (IODb) [2] because of a
>>> statement in their ticket that (they) "would be using Bing imagery
>>> **without any offset **while correcting existing network and/or add missing
>>> roads" (emphasis in mine) , but that phrase was nowhere in their email to
>>> the mailing list.
>>>
>>> The Grab team has been quite responsive in the past, to address the
>>> concerns we've had with them and they are still that to this day. Kudos
>>> Grab team!
>>>
>>> Eugene made note of the vague description of their task and asked them
>>> to elaborate, which they did [3] and they also identified the specific
>>> objects they plan to work on.
>>>
>>> The ensuing conversations, however, were in the OpenStreetMap Asia's
>>> Telegram channel [4], and so they were asked to pursue the detailed
>>> discussion in this list to make the rest of the discussions public, and
>>> accessible to the rest of the community.
>>>
>>> To restart the conversation, I'll respond to the query [5] made by
>>> Lavanya regarding the Imagery Offsets plugin for JOSM.  ( If you're new
>>> with that plugin, this short introduction [6] will help you get started. )
>>>
>>> In a later image they posted [7] on Telegram which they described as
>>> "conflicting" with the image label: "offset in josm for same location 3m" ,
>>> they appear to have misinterpreted distance of the location where the
>>> offsets adjustments were set ("296m" east of their current location) and
>>> the actual offset distance ("3m") that has led to their conclusion that it
>>> was "conflicting".
>>>
>>> Back on my desk, I replicated their JOSM setup to get a clearer image,
>>> and as seen in this screen cap [11], the record actually match with what
>>> was found in the offset record in question [9].  Therefore, there's no
>>> actual conflict.
>>>
>>> The offset in question [9] was made by Rally during the course of our
>>> work with the NCR road alignment validation with Kaart [10] that was
>>> completed in June.
>>>
>>> I believe the