Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Aury88]

Alessandro Sarretta wrote
> Ciao Aury, tutto vero.
> Per quello chiedevo se queste discussioni erano state già sviscerate in 
> passato...
> Immagino che un processo di verifica causerebbe problemi per editing 
> concorrenti da utenti "esperti" sulle stesse aree o oggetti, con 
> incastri di revisioni e versioni credo non banali.
> L'esistenza di una modalità di utente "sotto controllo/validazione", da 
> attivare in modo semi automatico dopo la segnalazione ad es. di 3-5 
> utenti " potrebbe però aiutare con utenti molto disattenti o 
> espressamente vandali.
> Qualcosa secondo me bisogna inventarsi...
> Ale

esatto, me lo ero scordato...hai ragione, c'è anche il problema inverso per
le aree con frequenti edit in cui un edit successivo a quello del nuovo
arrivato viene accettato prima rendendo parzialmente inapplicabile l'edit
del nuovo utente (= altri casini)



l'ultima che hai detto mi sembra il miglior compromesso: mettere sotto
sorveglianza solo gli utenti segnalati ...se avessimo anche la possibilità
di segnalare un dato in attesa di validazione si potrebbe superare il
problema del rischio versioni in conflitto...rimarebbe solamente il problema
duplicazioni di facile risoluzione.

il problema l'ho visto affrontato in varie  ML e in qualche diario, e forse
anche qui è nata qualche discussione, ma non si è mai giunti ad una
soluzione soddisfacente...per esempio alla mia proposta si è preferito prima
un sistema captcha poi scartato perchè "di proprietà di google"...e alla
fine non si è fatto nulla.
attualmente il sistema funziona molto bene dove c'è una comunità esperta
attiva (o meglio un certo rapporto tra utenti esperti/nuovi utenti) che,
sfruttando anche gli ottimi e variegati tool di QA, è in grado di
intervenire su gli edit errati/vandalici prima di un successivo edit...

ciao aury




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

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

[talk-ph] Fwd: [info-hotosm] Inquiry About HOT in the Philippines

[maning sambale]

-- Forwarded message --
From: maning sambale 
Date: Sun, Feb 25, 2018 at 8:10 AM
Subject: Re: [info-hotosm] Inquiry About HOT in the Philippines
To: Blake Girardot HOT/OSM 
Cc: Rabby Lavilles 


Thanks for the intro Blake.
@Rabby lmk, the specifics, we can hop on a call with other core mappers if
you want.

On Sat, Feb 24, 2018 at 11:34 AM, Blake Girardot HOT/OSM <
blake.girar...@hotosm.org> wrote:

> Hi Rabby,
>
> OSM is very active in the Philippines.
>
> I am including my colleague Maning on this email to connect you two, I am
> pretty sure Maning is still based there, my apologizes if that is not the
> case Maning.
>
> Also, there is an email list dedicated to OSM-PH:
> https://lists.openstreetmap.org/listinfo/talk-ph
>
> The OSM Wiki has some historical info on the OSM-PH community:
> https://wiki.openstreetmap.org/wiki/WikiProject_Philippines
> https://wiki.openstreetmap.org/wiki/OpenStreetMap_Philippines_Inc.
>
> And they look to have an active Facebook page as well:
> https://www.facebook.com/OSMPH/
>
> I think you will be in good hands here, please let us know if we can be of
> any additional help.
>
> Respectfully,
> blake
>
>
> On Sat, Feb 24, 2018 at 6:40 AM, Rabby Lavilles <
> rabby_lavil...@dlsu.edu.ph> wrote:
>
>> Hello,
>>
>> I am part of Disaster Management Project of De La Salle
>> University-Manila, Philippines. As part of our initial findings in Legazpi
>> (one of the cities in the Philippines), they need to manage and update
>> their maps to be able to support disaster plans and mitigation. We
>> introduce to them OpenStreetMap as one of the tools they can be used to
>> update their maps. However, they asked us how we can help them in
>> conducting community mapping. The group decided to conduct a mapping
>> activity (using OpenStreetMap) to participating government and
>> non-government organizations involved in disaster management of the city.
>>
>> As an exploring user of OpenStreetMap, I would like to ask if there is a
>> support group in the Philippines that we can refer to as a start; for us to
>> develop our workshop.
>>
>> Hope to hear from you. Thank you so much.
>>
>> Sincerely,
>>
>>
>> Rabby Q. Lavilles
>> De La Salle University-Manila
>>
>>
>>
>>  
>>  
>>  
>>
>> DISCLAIMER AND CONFIDENTIALITY NOTICE
>> The information contained in this e-mail, including those in its
>> attachments, is confidential and intended only for the person(s) or
>> entity(ies) to which it is addressed. If you are not an intended recipient,
>> you must not read, copy, store, disclose, distribute this message, or act
>> in reliance upon the information contained in it. If you received this
>> e-mail in error, please contact the sender and delete the material from any
>> computer or system. Any views expressed in this message are those of the
>> individual sender and may not necessarily reflect the views of De La Salle
>> University.
>>
>
>
>
> --
> 
> Blake Girardot
> Humanitarian OpenStreetMap Team
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-br] Fundar Associação OpenStreetMap Brasil

[santamariense]

Olá caros colegas,

Surgiu o assunto sobre criarmos um Tasking Manager brasileiro, e a
partir das discussões sobre a falta de um, sobressaiu também a
discussão sobre termos algo mais abrangente e concreto, como uma
Associação/Organização.

Sabemos que isso já vem sendo pensado há um bom tempo, e estamos
querendo pôr em prática, por diversos motivos e objetivos. Tudo está
sendo documentado em
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associação

Ajude a preencher os seguintes tópicos. Sempre baseado no que já
estiver na wiki.

* Objetivos

* Lista de necessidades, possibilidades, meios e custos

* Propostas de organização interna

* Apoio financeiro

[em caso de pessoal física, se você tiver pré-interesse em ajudar
financeiramente, adicione seu nome (de usuário) na wiki, ou, peça para
adicionarem]

Sua participação é muito importante e fundamental

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

Re: [Talk-at] Toiletten & Museen in Wien

[Friedrich Volkmann]

On 24.02.2018 20:36, Markus Straub wrote:
Wir werden dafür POIs aus OSM verwenden, genau genommen Museen & Toiletten. 
Die Museen werde ich mir die Tage näher anschauen (und v.a. Webseiten / 
Adressen ergänzen), weil das gut mit Internetrecherche machbar ist.


Ich war schon in den meisten Wiener Museen und habe manche sogar 
indoorgemappt (mit level, Fläche, Eingang). Wenn sich was verbessern lässt, 
dann wahrscheinlich weniger an den Daten als an der App. Also bitte nicht 
alles umtaggen.


Bei den Toiletten ist es aber schwieriger, da hilft eigentlich nur 
Vor-Ort-Kenntnis.


Klos gibt es in Wien wahrscheinlich Millionen. Ich nehme an, du meinst die 
frei zugänglichen, aber auch da muss man unterscheiden zwischen 
Gratisbenutzung, Benutzung gegen Gebühr und Kunden-WCs. Außerdem haben nicht 
alle den ganzen Tag offen, z.B. sind die U-Bahn-Stationen außerhalb der 
Betriebszeiten gesperrt und damit auch die Klos. Und dann gibt es auch noch 
verschiedene Qualitätsstandards, von den immer sauberen Asfinag-WCs bis zu 
den Plumpsklos auf der Donauinsel.


Ehrlich gesagt erscheint mir so ein Projekt ein bisschen weltfremd. Was 
haben Museen und Klos miteinander zu tun (außer dass es Klos auch in Museen 
gibt)? Das passt doch überhaupt nicht zusammen. Ein Klo braucht man 
unterwegs eher unvorhergesehen, ein Museum hingegen besucht man nach 
Vorplanung. Man schaut sich schon zuhause an, wie man zum Museum hinkommt, 
und dann braucht man unterwegs kein Tablet mehr. Grad wenn du mit 
Pensionisten zu tun hast, musst du damit rechnen, dass sie vorher sagen, 
jaja, ich werde das Tablet benutzen; und dann entscheiden sie sich doch für 
einfachere Mittel, z.B. einen Stadtplan auf Papier, denn alte Leute sind 
noch geübt im Kartenlesen.


Außerdem musst du damit rechnen, dass alte Wiener schon etliche Museen 
kennen. Keiner muss auf einen Plan schauen um das Belvedere oder das 
Naturhistorische Museum zu finden. Kritisch sind nur die weniger bekannten 
Museum, z.B. das Ziegelmuseum und die Neidhartfresken, oder neue wie das 
Frankl-Museum.


Wenn es sich jemand wirklich antut, sich der Navigation mittels Tablet 
anzuvertrauen, dann könnte er es spätestens in der U-Bahn, wo er den 
GPS-Empfang verliert, bereuen.


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

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

[OSM-talk] An OSM logo for translation projects

[dcapillae]

Hi,

Some time ago, the OSM community in Spain had a discussion [1] to add a
country template and choose a new image for our wiki page on the OSM Wiki
[2].

The OSM community in Spain has been using an OSM logo with the letters "ES"
[3]. This logo was the same one that we were using in the WikiProject
Spanish translation [4].

The Spanish-speaking OSM community in the world is not limited to Spain.
Therefore, to avoid confusion between OSM Spain and OSM "in Spanish", we
have changed the logo for this one [5], a simple and more generic logo which
can be used in your OSM translation projects and wikiprojects.

Greetings from Spain.

[1]
https://wiki.openstreetmap.org/wiki/ES_talk:Espa%C3%B1a#A.C3.B1adir_plantilla_de_lugar
(in Spanish)
[2] https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a (in Spanish)
[3] https://wiki.openstreetmap.org/wiki/File:Osm_es.svg
[4]
https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Traducci%C3%B3n_en_espa%C3%B1ol
(in Spanish)
[5] https://wiki.openstreetmap.org/wiki/File:OSM_translation.svg


P.S.: Sorry if this message is published twice. I forgot to subscribe to the
list before sending it.



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/02/18 20:49, Martin Koppenhoefer wrote:

Every country may have different peculiarities, but the general concept is the 
same: a road usually restricted to motorized traffic, typically grade separated 
and distinct carriageways.

We’re normally using British English in tagging but this doesn’t mean we 
couldn’t map things that don’t occur in the UK or for what they don’t have a 
word.


I think the main problem is that there are well established guidelines 
for various areas on mapping data at both country and region level but 
in may cases even those rules do not harmonize. We need the several 
levels of highway that are currently accurately mapping UK roads, but 
other areas of the world do not need that degree of classifications ... 
so they just don't use the ones that are not appropriate ...


( And I am battling getting my computer working again as it was such as 
getting email replies properly handled on different lists :( )


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

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

Re: [Talk-at] Toiletten & Museen in Wien

[Peter Müller]

Gerade nachgeschaut, alle klos die ich kenne sind schon drinnen.

> Gesendet: Samstag, 24. Februar 2018 um 20:36 Uhr
> Von: "Markus Straub" 
> An: "OpenStreetMap AT" 
> Betreff: [Talk-at] Toiletten & Museen in Wien
>
> Hallo,
> 
> ich bin Teil des Projektteams von http://www.waalter.wien - einem 
> Forschungsprojekt bei dem ab März >80 Haushalte von älteren Menschen mit 
> u.a. einem Tablet ausgestattet werden, auf dem es auch eine Wegfinderapp 
> geben wird.
> 
> Wir werden dafür POIs aus OSM verwenden, genau genommen Museen & 
> Toiletten. Die Museen werde ich mir die Tage näher anschauen (und v.a. 
> Webseiten / Adressen ergänzen), weil das gut mit Internetrecherche 
> machbar ist.
> Bei den Toiletten ist es aber schwieriger, da hilft eigentlich nur 
> Vor-Ort-Kenntnis.
> 
> In beiden Fällen habe ich gemerkt, dass die OGD der Stadt Wien leider 
> veraltert und unvollständig, also auch keine große Hilfe sind. So sind 
> z.B. abgerissene Toiletten enthalten während alle Inselklos und Klos in 
> U-Bahn-Stationen fehlen.
> 
> Wenn ihr also einen Blick auf die euch bekannten Toiletten (und Museen) 
> werfen könntet wär das super, dann kann OSM in WAALTeR mit aktuellen 
> Daten glänzen.
> 
> Liebe Grüße,
> Markus / evod
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

[Talk-GB] Geospatial User Workshops

[Rob Nickerson]

Gregory attended the workshop in Leeds. Here is the write-up:

https://osmuk.org/uncategorized/feedback-mastermap-geospatial-user-workshop/

There are events on Tuesday and Wednesday in Bristol and Cardiff
respectively. Feel free to also share feedback with OSM UK and we will
collate and pass them on to the Geospatial Commission.

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

[Talk-at] Toiletten & Museen in Wien

[Markus Straub]

Hallo,

ich bin Teil des Projektteams von http://www.waalter.wien - einem 
Forschungsprojekt bei dem ab März >80 Haushalte von älteren Menschen mit 
u.a. einem Tablet ausgestattet werden, auf dem es auch eine Wegfinderapp 
geben wird.


Wir werden dafür POIs aus OSM verwenden, genau genommen Museen & 
Toiletten. Die Museen werde ich mir die Tage näher anschauen (und v.a. 
Webseiten / Adressen ergänzen), weil das gut mit Internetrecherche 
machbar ist.
Bei den Toiletten ist es aber schwieriger, da hilft eigentlich nur 
Vor-Ort-Kenntnis.


In beiden Fällen habe ich gemerkt, dass die OGD der Stadt Wien leider 
veraltert und unvollständig, also auch keine große Hilfe sind. So sind 
z.B. abgerissene Toiletten enthalten während alle Inselklos und Klos in 
U-Bahn-Stationen fehlen.


Wenn ihr also einen Blick auf die euch bekannten Toiletten (und Museen) 
werfen könntet wär das super, dann kann OSM in WAALTeR mit aktuellen 
Daten glänzen.


Liebe Grüße,
Markus / evod

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

Re: [Talk-at] Vervollständigung der Wiener Adressen

[gppes_osm]

Ich moechte jetzt allgemein zur Adressdiskussion meinen Senf dazu geben. Nachdem ich schon sehr viele Adressen in Datenbank eingetragen* habe, habe ich auch ein bisschen Erfahrung gesammelt.

 

 

Ich schliesse mich im grossen und ganzen der Haltung KaiRos an.

Adressen sollen im Allgemeinen auf den Gebaeudeumriss, in komplexeren Faellen an den Hauseingang. So steht es derzeit auch im Wiki.

 

Ident-Adressen an POIs halte ich fuer unwahrscheinlich. Ich habe in Leoben in einem Haus mit Ident-Adresse an einer POI persoenlich angefragt, ob beide Adressen verwendet werden. Mit grossem Unverstaendnis wurde mir erklaert: "Ja wie kompliziert willst Du es denn haben? Eine Adresse reicht uns voellig!".

 

Lg, Gppes


 

* Auch wenn ich nicht behaupten will, dass Wiederholung des immer selben wirklich gescheiter machen muss...


Gesendet: Samstag, 24. Februar 2018 um 19:12 Uhr
Von: "Markus Straub" 
An: "OpenStreetMap AT" 
Betreff: [Talk-at] Vervollständigung der Wiener Adressen

Hallo,

ist noch jemand hier motiviert (bzw. gerade dabei) die Adressen in Wien
zu vervollständigen? Abseits der Stiegendiskussion gibt es ja noch
genügend klare Fälle von Einfamilienhäusern in der Peripherie (z.B. im
21. und 22. Bezirk - Breitenlee, Essling, Schwarze Lackenau,
Nordrandsiedlung,..)

Ich fände es auch super wenn wir noch heuer sagen können, dass in Wien
alle Adressen & Häuserumrisse komplett sind - an der Zeit wärs :)

Welche Tools verwendet ihr? Ich arbeite gerade mit

- JOSM + HouseNumberTaggingTool
(https://josm.openstreetmap.de/wiki/Help/Plugin/HouseNumberTaggingTool)
-
https://wambachers-osm.website/addr/#zoom=12=48.2229=16.4195=Openstreetmap.org%20Grayscale=FTFFF
- OGD Hintergrundkarte (Gebäudeumrisse / Adressen) von wien.gv.at
- http://osm-austria-building-coverage.thomaskonrad.at/

Was verwendet ihr um das Mappen möglichst flott & exakt zu halten?

LG, Markus / evod

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




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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Sat, Feb 24, 2018 at 2:51 PM, Martin Koppenhoefer
 wrote:
> can you please point to some examples? Are you sure about the other maps? 
> They often don’t show many different road classes on first sight (but they 
> have them and you can see it as you zoom in and out that there must be more 
> properties or classes than you can distinguish by color or width)

Sure. Let's begin with Matej's example: route 7 on Sulec, Czechia.
It's not continuous in OSM, but it is in Google Maps, Here.com and
Waze:
- https://www.openstreetmap.org/#map=14/50.3083/13.8837
- https://www.google.com.br/maps/@50.30831134,13.88367320,14z
- https://wego.here.com/?map=50.30828,13.88449,14,normal

In Germany, there are many small stretches of trunk in the area
between Berlin, Hamburg and Hannover. On the route Hamburg - Uelzen -
Braunschweig, it happens twice along route B4:
- in Uelzen: https://www.openstreetmap.org/#map=13/52.9611/10.5890
- in Gifhorn: https://www.openstreetmap.org/#map=13/52.4694/10.5244

No such changes in Google Maps, Here.com or Waze.

In Openstreetmap.de, this leads to the interesting effect of knowing
where the road is divided. However, that does not translate well
elsewhere - for example, in England, on route A40 between Oxford and
Gloucester, which is not divided:
https://www.openstreetmap.de/karte.html?zoom=18=51.80304=-1.63750=B000TT

In Italy, on route SS12 between Verona and Modena, it also happens twice:
- in Isolda della Scala: https://www.openstreetmap.org/#map=13/45.2730/11.0218
- in Mirandola: https://www.openstreetmap.org/#map=13/44.8679/11.0485

As in the other example, no such changes in Google Maps, Here.com or Waze.

-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [Talk-at] Vervollständigung der Wiener Adressen

[gppes_osm]

Hallo,

 

unabhaengig von der Diskussion hier: Wenn Du Dich an das Wiki haeltst kannst  Du auch in Wien versuchen jede Adresse zu mappen und es kann keiner was dagegen haben.

 

Das HouseNumberTaggingTool ist eine  tolle Sache, aber in Oesterreich empfiehlt  sich wirklich dieses Josm Plugin:

https://openstreetmap.at/2017/03/josm-plugin-fuer-oesterreichische-adressen-des-bev/

Man  kann dieses Tool gar nicht genug  loben, eigentlich sollte man  Jubelchoere anstimmen.

 

Bitte gleiche die Ergebnisse mit  der basemap ab, beide Quellen sind nicht immer perfekt, zusammen erreicht man vermutlich die besten Ergebnisse.

 

Als Obersteirer werde ich mich in Wien aber nicht bis kaum beteiligen.

 

Lg, Gppes

 

Gesendet: Samstag, 24. Februar 2018 um 19:12 Uhr
Von: "Markus Straub" 
An: "OpenStreetMap AT" 
Betreff: [Talk-at] Vervollständigung der Wiener Adressen

Hallo,

ist noch jemand hier motiviert (bzw. gerade dabei) die Adressen in Wien
zu vervollständigen? Abseits der Stiegendiskussion gibt es ja noch
genügend klare Fälle von Einfamilienhäusern in der Peripherie (z.B. im
21. und 22. Bezirk - Breitenlee, Essling, Schwarze Lackenau,
Nordrandsiedlung,..)

Ich fände es auch super wenn wir noch heuer sagen können, dass in Wien
alle Adressen & Häuserumrisse komplett sind - an der Zeit wärs :)

Welche Tools verwendet ihr? Ich arbeite gerade mit

- JOSM + HouseNumberTaggingTool
(https://josm.openstreetmap.de/wiki/Help/Plugin/HouseNumberTaggingTool)
-
https://wambachers-osm.website/addr/#zoom=12=48.2229=16.4195=Openstreetmap.org%20Grayscale=FTFFF
- OGD Hintergrundkarte (Gebäudeumrisse / Adressen) von wien.gv.at
- http://osm-austria-building-coverage.thomaskonrad.at/

Was verwendet ihr um das Mappen möglichst flott & exakt zu halten?

LG, Markus / evod

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



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

Re: [OSM-talk-fr] Usage d'OSM par les services de secours du pays-bas

[Philippe Verdy]

C'est bien dommage car c'est plus adapté à l'arrêt, c'est souvent
gravillonné, et tout à fait adapté à **l'arrêt** momentané des véhicules
laissant le passage à un véhicule d'urgence sur la chaussée normale où ils
peuvent rouler dans de meilleures conditions. Le comportement des
néerlandais n'est pas stupide, d'autant plus qu'il ne font en mettant les
warnings pour bien signaler l'arrêt; le but est bien l'arrêt d'urgence
(même si l'urgence ne les concerne pas directement).

Et ce comportement me semble moins dangereux que de laisser les véhicules
d'urgence rouler vite sur une bande où il peut y avoir des véhicules
arrêtés à tout moment.

On le voit, les Néerlandais utilisent cette bande aussi pour laisser le
passage dans les virages des bretelles d'accès ou de sortie, là encore avec
les warnings, ils le font aussi pour s'arrêter sur les zones zébrées, là
encore avec les warnings.

Je trouve cela très très bien et cela devrait être conseillé et enseigné en
France !

Evidemment, une fois le véhicule d'urgence passé, il faut se réinsérer
prudemment sur la voie normale, on n'y stationne pas, personne ne roule
dessus à pleine vitesse, pas plus ceux qui s'y arrêtent que les véhicules
d'urgence (qui ne devraient être contraints à le faire
qu'exceptionnellement, si les véhicules bloqués dans une file d'un bouchon
ne peuvent pas la dégager rapidement en utilisant cette bande : s'ils sont
déjà arrêtés, ils doivent rester dans leur file et ne pas dégager sur cette
bande sans avoir au départ bien regardé qu'il ne venait pas un véhicule
d'urgence, ou seulement parce que ce véhicule ou un policier le leur
demande) !


Le 24 février 2018 à 17:28, djakk djakk  a écrit :

> En France c’est la bande d’arrêt d’urgence qui sert de voie de circulation
> aux véhicules d’urgence ;-)
>
>
> Le sam. 24 févr. 2018 à 17:01, Philippe Verdy  a
> écrit :
>
>> Je suis admiratif sur la façon dont les conducteurs aux Pays-Bas font de
>> leur mieux pour laisser le passage aux véhicules d'urgence, se parquent sur
>> les voies d'arrêt d'urgence (en mettant les warnings), n'entrent pas dans
>> un carrefour même si le feu est vert pour eux, et signalent même les
>> véhicules devant eux pour leur signaler et faire la même chose. Et tout le
>> monde respecte ça, il n'y en a pas qui profitent de ce dégagement de la
>> voie pour doubler une file dans un bouchon et passer devant le véhicule
>> d'urgence.
>>
>> Même dans le cas d'une bretelle de sortie où il y a une réduction du
>> nombre de voies, ils n'hésitent pas à s'arrêter (et allumer leur warning)
>> sur leur voie, pour ne pas fusionner dans la voie unique qu'ils laissent
>> libre pour le passage de l'ambulance. La voie d'arrêt d'urgence sur les
>> autoroutes et voies express est toujours libre pour pouvoir s'y arrêter et
>> laisser le passage en toute sécurité si nécessaire. Les conducteurs
>> néerlandais sont prévoyants (hormis le cas d'un seul camion dans la vidéo
>> qui est passé et a bloqué le passage du véhicule d'urgence, il devait être
>> étourdi mais il était le seul).
>>
>> Même les camions et certains véhicules respectent ça et sont équipés pour
>> certains de feux clignotants spéciaux (à clignotement rapide) pour signaler
>> au véhicule d'urgence qu'ils ont laissé un passage libre sur la voie qu'ils
>> ont dégagé (les autres véhicules utilisent au minimum leurs feux "warning"
>> quand ils manœuvrent pour se ranger).
>>
>> On n'a pas les même comportements en France, par exemple sur les bandes
>> d'arrêt d'urgence sur nos autoroutes ou sur les périphériques parisiens ou
>> nantais (sans toutefois atteindre les sommets de l'imprudence et
>> l'incivilité qu'on voit en Russie, où nombre de conducteurs plus prudents
>> ont installé des caméras embarquées avec enregistrement dans leur véhicule
>> pour faire preuve et témoigner des imprudences des autres : les vidéos
>> d'accidents en Russie, prises avec ces caméras embarquées, sont terribles
>> et ça doit être vraiment dangereux pour les véhicules d'urgence d'oser
>> franchir un feu rouge même s'ils sont "prioritaires" selon la loi).
>>
>> 2018-02-24 10:20 GMT+01:00 David Crochet :
>>
>>> Bonjour
>>>
>>> petite vidéo avec OSM et surcouches : https://youtu.be/_jGGZq6_6hw?t=334
>>>
>>> Cordialement
>>>
>>> --
>>> David Crochet
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

> On 24. Feb 2018, at 13:02, Lester Caine  wrote:
> 
> Since the classification initiated from the UK, that is still the base and a 
> motorway has restrictions that do not apply to a trunk route such as 'no 
> learners'.


what are “learners”? I don’t think we are required to map the whole world 
according to the UK jurisdiction.


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

[Talk-at] Vervollständigung der Wiener Adressen

[Markus Straub]

Hallo,

ist noch jemand hier motiviert (bzw. gerade dabei) die Adressen in Wien 
zu vervollständigen? Abseits der Stiegendiskussion gibt es ja noch 
genügend klare Fälle von Einfamilienhäusern in der Peripherie (z.B. im 
21. und 22. Bezirk - Breitenlee, Essling, Schwarze Lackenau, 
Nordrandsiedlung,..)


Ich fände es auch super wenn wir noch heuer sagen können, dass in Wien 
alle Adressen & Häuserumrisse komplett sind - an der Zeit wärs :)


Welche Tools verwendet ihr? Ich arbeite gerade mit

- JOSM + HouseNumberTaggingTool 
(https://josm.openstreetmap.de/wiki/Help/Plugin/HouseNumberTaggingTool)
- 
https://wambachers-osm.website/addr/#zoom=12=48.2229=16.4195=Openstreetmap.org%20Grayscale=FTFFF

- OGD Hintergrundkarte (Gebäudeumrisse / Adressen) von wien.gv.at
- http://osm-austria-building-coverage.thomaskonrad.at/

Was verwendet ihr um das Mappen möglichst flott & exakt zu halten?

LG, Markus / evod

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

> On 24. Feb 2018, at 11:16, Matej Lieskovský  
> wrote:
> 
> One last observation:
> Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and Slovakia 
> all use a similar system where highway=trunk is "motorway-like", with trunk 
> either implying motorroad status, or being a prerequisite for it.


add Italy to this list, although motorroad is somehow orthogonal to trunk, in 
Germany and Italy at least.

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Cascafico Giovanni]

Il FVG non è molto popoloso, quindi riesco spesso a commentare il changeset
dell'utente novellino, che debbo dire risponde 9/10. In genere dopo 2-3
changeset comincia ad essere produttivo.

Altra cosa per i vandali. Secondo voi, sarebbe possibile passare alla
validazione utente via sms?

Il giorno 24 febbraio 2018 18:54, Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> On 24/02/2018 18:18, Aury88 wrote:
> Per quello chiedevo se queste discussioni erano state già sviscerate in
> passato...
> Immagino che un processo di verifica causerebbe problemi per editing
> concorrenti da utenti "esperti" sulle stesse aree o oggetti, con incastri
> di revisioni e versioni credo non banali.
> L'esistenza di una modalità di utente "sotto controllo/validazione", da
> attivare in modo semi automatico dopo la segnalazione ad es. di 3-5 utenti
> " potrebbe però aiutare con utenti molto disattenti o espressamente vandali.
> Qualcosa secondo me bisogna inventarsi...
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Dt. Kartenstil: Rendern von historic=fort

[Christoph Hormann]

On Saturday 24 February 2018, Sven Geggus wrote:
>
> Die Symbole für Burgen und Schlösser im dt. Stil stammen aus ATKIS,
> sind also gar nicht mal so sehr auf Deutschland begrenzt. Ich
> bräuchte aber halt eine Lösung für historic=fort um zu versuchen das
> Ganze upstream als pull-request einzureichen.

Wenn man jetzt historic=castle differenziert nach castle_type darstellt 
könnte man überlegen, historic=fort als eine Variante davon zu zeigen.  
Das ist aber im Grunde auch nicht wirklich gut, denn historic=fort ist 
ja sehr generisch für alle Arten von Bauwerken, die ehemals für 
Verteidigungszecke gebaut und konzipiert worden sind während 
castle_type eigentlich wesentlich spezifischer differenziert.  Aber das 
wäre immer noch viel besser als jetzt.

Aber ein geeignetes Symbol, welches nicht einen bestimmten 
kultur-spezifischen Festungs-Stil kommuniziert fällt mir da nicht 
wirklich ein.

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

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Alessandro Sarretta]

On 24/02/2018 18:18, Aury88 wrote:

per quanto il sistema di validazione sul singolo utente sia certamente meno
oneroso e più efficace dell'attuale sistema di  "commento/avviso/interazione
con DWG/blocchi vari " come dice giustamente Alessandro, è anche vero che il
sistema attuale si usa solo quando necessario, cioè solo in presenza di un
vandalo o per un edit effettivamente errato, non si usa per tutti i nuovi
utenti che si registrano.
le statistiche dicono che ci sono tra i 15000 e i 2 contributori nuovi
ogni mese che moltiplicati per gli x changeset necessari (tr l'altro quanto
grandi? io ho visto changeset da singoli cambiamenti a quelli contenenti
anche una cinquantina), invece quanti sono attualmente gli interventi di
revert al mese?
bisognerà che qualcuno si prenda l'onere di controllare i nuovi arrivati
pena il fallimento del progetto per assenza di sufficienti nuovi ingressi di
utenti. e chi deve controllare per giudicare un changeset? non tutti gli
atti vandalici sono evidenti...basta un senso unico invertito (anche per
errore)...servirebbe quindi spesso un utente esperto locale, cosa che però
farebbe fallire tutto il metodo per le aree non coperte da un utente
storico.

insomma tranti pro e contro :-/

Ciao Aury, tutto vero.
Per quello chiedevo se queste discussioni erano state già sviscerate in 
passato...
Immagino che un processo di verifica causerebbe problemi per editing 
concorrenti da utenti "esperti" sulle stesse aree o oggetti, con 
incastri di revisioni e versioni credo non banali.
L'esistenza di una modalità di utente "sotto controllo/validazione", da 
attivare in modo semi automatico dopo la segnalazione ad es. di 3-5 
utenti " potrebbe però aiutare con utenti molto disattenti o 
espressamente vandali.

Qualcosa secondo me bisogna inventarsi...
Ale


--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

> On 24. Feb 2018, at 03:47, Fernando Trebien  
> wrote:
> 
> None of the
> commercial alternatives to OSM have such artifacts.


can you please point to some examples? Are you sure about the other maps? They 
often don’t show many different road classes on first sight (but they have them 
and you can see it as you zoom in and out that there must be more properties or 
classes than you can distinguish by color or width) 


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

On 24. Feb 2018, at 03:47, Fernando Trebien  wrote:

>> drawn as a trunk road hints at all
>> these changes.
> 
> 
> You could also map it with lanes=4+foot=no+bicycle=no+agricultural=no
> and let the renderer decide whether these things are worthy of special
> representation or not.


there’s more to it, e.g. absence of traffic lights or level crossings (i.e. 
only ramps), separate carriageways, etc.
You can’t see the absence of traffic lights reliably in OSM, for example, and I 
imagine checking automatically for the type of crossings is also rather 
complex, just to be able to draw the road.


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

> On 23. Feb 2018, at 19:31, Fernando Trebien  
> wrote:
> 
> Assuming the map is correctly classified in Europe, I'm seeing many
> fragments of motorways and trunks all over the map. Is this an
> artifact of local definitions


it is because motorroads are defined legally (signs) and trunks typically 
according to physical status (e.g. motorway like), and in reality the networks 
often aren’t complete, which is reflected correctly on the map (in general) by 
showing those “gaps”


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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Rpnpif]

Le 24 février 2018, Christian Quest a écrit :

> Le 23 février 2018 à 22:35, marc marc  a écrit :
> 
> > Bonjour,
> >
> > Le 23. 02. 18 à 12:31, Christian Quest a écrit :  
> > > JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5
> > > objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets).  
> >
> > La limite du changeset a été baissé de 50k à 10k l'an passé
> > https://wiki.openstreetmap.org/w/index.php?title=API_v0.
> > 6=next=1431627
> > $ wget -q -O - https://api.openstreetmap.org/api/capabilities
> >  
> > josm sait gérer les multiples changeset  mais il a aussi un mode
> > qui n’envoie qu'un changeset, c'est peut-être cela qui s'est passé.
> >
> >  
> Oups, j'avais pas vu ça... ça montre bien à quel point c'est transparent ;)
> 
> 

Je vais reprendre l'ensemble des nœuds que j'ai transférés et les
corriger dans les jours qui viennent.
Je viens d'essayer avec deux petits ruisseaux d'une dizaine de nœuds
après les avoir peaufinés : fusion, jointure en aval, simplification ce
qui diminue le nombre de nœuds, élimination des attributs non conformes
puis transfert de la sélection, vérification dans OSM.

Et ça marche impeccable... c'est juste un peu plus long mais plus
propre effectivement. Je continuerai ainsi de ruisseau en ruisseau.

Merci à tous ceux qui m'ont conseillé et m'ont permis de mieux
comprendre la philosophie de JOSM qui est plus limité ou plutôt moins
automatisé que ce que je pensais. J'essaierai encore d'en apprendre plus
dessus.

Bon dimanche.

-- 
Alain Rpnpif

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Martin Koppenhoefer]

sent from a phone

> On 23. Feb 2018, at 19:29, djakk djakk  wrote:
> 
> Don’t worry, when the official system is good, lik in Czechia, it matches 
> Fernando’s suggestion :)


usually you’ll find several “classes” for roads by the public administration, 
according to the purpose/point of view, at least in Germany and Italy that’s 
the case. There can be classes according to the importance of connection, 
frequency of use, and maybe correlated with this size (number and width of 
lanes) and typology, setting, intensity of maintenance, etc. (some of these 
classes might only be known to the engineers who design the road / network, or 
organize the maintenance).
The only “class” you can often easily see is about _who_ does the maintenance 
(e.g. national/regional/municipality/etc), which is a property we do map as 
operator. It can occur that there is a strong relationship between the 
hierarchy of the operators and the importance of the road, but it is generally 
unlikely that there aren’t any exceptions at all (e.g. because the public 
administration is usually slow and it will take some time for them to adopt to 
changed conditions)


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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Aury88]

Alessandro wrote
> Ciao Aury,
> questa procedura potrebbe eliminare i bot ma non avrebbe effetto nè su 
> molti vandali (su qualcuno sì perchè si scoccerebbe) e aiuterebbe poco 
> chi commette errori per inesperienza.
> Sul lato implementazione poi ci sarebbe da capire come attuare la cosa, 
> ma almeno discuterne è già un primo passo.
> In realtà quello che tu indichi è nè più nè meno di quello che fa oggi 
> il tutorial di iD. Forse ci vorrebbe un qualcosa di più dei 3' della 
> durata del tutorial. La cosa positiva è che ci potrebbe prendere il 
> sistema del tutorial e ampliarlo, senza dover progettare il tutto da zero.
> 
> Alessandro Ale_Zena_IT
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

ripeto, l'idea era per affrontare la questione bot spam (questione che credo
sia in buona sostanza rientrata) e per istruire un po' gli utenti prima del
primo edit. non penso che un utente per quanto inesperto non sia in grado di
identificare il tetto di una casa o tracciare una strada (e naturalmente il
grado di difficoltà e la precisione richiesta nel compito deve essere
settato tenendo conto dell'inesperienza dell'utente)...se un utente non è in
grado di eseguire un compito, che ripeto sarebbe selezionato ed impostato
apposta perchè risulti affrontabile da un utente neo iscritto, dubito
sarebbe comunque in grado di contribuire ad OSM neanche nel più semplice dei
modi
la difficoltà di implementazione non era tanto lato software quanto il fatto
che un tale sistema impedisce il contributo da tutti quei servizi che, oltre
che sfruttare i dati osm, permettono di contribuire, come MAPS.ME...servizi
che all'atto del primo edit dovrebbero mostrare anch'essi il tutorial o
imporre un corso per l'editing

quel metodo naturalmente non blocca il vandalo ne l'ho mai spacciato per un
sistema che serve a risolvere o ad affrontare quel problema...ma di fatto in
tal senso l'utilità di un tutorial interattivo obbligatorio ha la stessa
identica efficacia di un "accademia" di ugual durata. rispetto al ranking è
ovviamente meno efficace ma ha il vantaggio di non inserire latenze tra
l'inserimento del dato e la sua "accettazione" (che per chi fa BBS sa
l'enorme effetto positivo che questo ha sul favorire un dato comportamento,
in questo caso il mappare per osm ) e di non richiedere e quindi aspettare
la validazione manuale per i primi x changeset dei nuovi utenti.
 per quanto il sistema di validazione sul singolo utente sia certamente meno
oneroso e più efficace dell'attuale sistema di  "commento/avviso/interazione
con DWG/blocchi vari " come dice giustamente Alessandro, è anche vero che il
sistema attuale si usa solo quando necessario, cioè solo in presenza di un
vandalo o per un edit effettivamente errato, non si usa per tutti i nuovi
utenti che si registrano.
le statistiche dicono che ci sono tra i 15000 e i 2 contributori nuovi
ogni mese che moltiplicati per gli x changeset necessari (tr l'altro quanto
grandi? io ho visto changeset da singoli cambiamenti a quelli contenenti
anche una cinquantina), invece quanti sono attualmente gli interventi di
revert al mese? 
bisognerà che qualcuno si prenda l'onere di controllare i nuovi arrivati
pena il fallimento del progetto per assenza di sufficienti nuovi ingressi di
utenti. e chi deve controllare per giudicare un changeset? non tutti gli
atti vandalici sono evidenti...basta un senso unico invertito (anche per
errore)...servirebbe quindi spesso un utente esperto locale, cosa che però
farebbe fallire tutto il metodo per le aree non coperte da un utente
storico.

insomma tranti pro e contro :-/




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

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

Re: [OSM-talk-fr] Usage d'OSM par les services de secours du pays-bas

[djakk djakk]

En France c’est la bande d’arrêt d’urgence qui sert de voie de circulation
aux véhicules d’urgence ;-)


Le sam. 24 févr. 2018 à 17:01, Philippe Verdy  a écrit :

> Je suis admiratif sur la façon dont les conducteurs aux Pays-Bas font de
> leur mieux pour laisser le passage aux véhicules d'urgence, se parquent sur
> les voies d'arrêt d'urgence (en mettant les warnings), n'entrent pas dans
> un carrefour même si le feu est vert pour eux, et signalent même les
> véhicules devant eux pour leur signaler et faire la même chose. Et tout le
> monde respecte ça, il n'y en a pas qui profitent de ce dégagement de la
> voie pour doubler une file dans un bouchon et passer devant le véhicule
> d'urgence.
>
> Même dans le cas d'une bretelle de sortie où il y a une réduction du
> nombre de voies, ils n'hésitent pas à s'arrêter (et allumer leur warning)
> sur leur voie, pour ne pas fusionner dans la voie unique qu'ils laissent
> libre pour le passage de l'ambulance. La voie d'arrêt d'urgence sur les
> autoroutes et voies express est toujours libre pour pouvoir s'y arrêter et
> laisser le passage en toute sécurité si nécessaire. Les conducteurs
> néerlandais sont prévoyants (hormis le cas d'un seul camion dans la vidéo
> qui est passé et a bloqué le passage du véhicule d'urgence, il devait être
> étourdi mais il était le seul).
>
> Même les camions et certains véhicules respectent ça et sont équipés pour
> certains de feux clignotants spéciaux (à clignotement rapide) pour signaler
> au véhicule d'urgence qu'ils ont laissé un passage libre sur la voie qu'ils
> ont dégagé (les autres véhicules utilisent au minimum leurs feux "warning"
> quand ils manœuvrent pour se ranger).
>
> On n'a pas les même comportements en France, par exemple sur les bandes
> d'arrêt d'urgence sur nos autoroutes ou sur les périphériques parisiens ou
> nantais (sans toutefois atteindre les sommets de l'imprudence et
> l'incivilité qu'on voit en Russie, où nombre de conducteurs plus prudents
> ont installé des caméras embarquées avec enregistrement dans leur véhicule
> pour faire preuve et témoigner des imprudences des autres : les vidéos
> d'accidents en Russie, prises avec ces caméras embarquées, sont terribles
> et ça doit être vraiment dangereux pour les véhicules d'urgence d'oser
> franchir un feu rouge même s'ils sont "prioritaires" selon la loi).
>
> 2018-02-24 10:20 GMT+01:00 David Crochet :
>
>> Bonjour
>>
>> petite vidéo avec OSM et surcouches : https://youtu.be/_jGGZq6_6hw?t=334
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[djakk djakk]

Par exemple : le Vercors : au nord, la limite floue pourrait être entre la
ligne de crête des montagnes et la rivière de l'Isère.
Je ne vois pas comment appliquer une largeur prédéfinie ...

djakk


Le sam. 24 févr. 2018 à 17:13, Philippe Verdy  a écrit :

> 2 ou trois géométries c'est souvent excessif.
>
> En pratique il suffira d'une seule limite. En avoir plusieurs complique
> énormément le rendu (et là ça nécessite des rôles spéciaux).
>
> Le tag "fuzzy=yes/no/distance en mètres" suffira la plupart du temps pour
> marquer les chemins (et certains noeuds). Et cela suffit aussi pour taguer
> les noeuds isolés dont la précision est floue. (fuzzy=yes n'indique aucune
> distance maximale pour le noeud, mais cette distance peut être sur le way
> qui contient la distance par défaut applicable tout le long du way, sauf
> aux derniers triangles joints à des noeuds "précis" avec "fuzzy=no" ou
> indiquant une précision avec fuzzy=distance en mètres".
>
> Si on met plusieurs géométries, au lieu de créer de nouvelles relations
> (symptôme de la "relationite aiguë"), là je vois plutôt utiliser les
> relations existantes avec des rôles modifiés ("inner"/"outer" deviennent
> "inner_max"/"outer_max" pour que ces extensions maximales puissent être
> facilement ignorées par les rendus qui ne savent pas ce que c'est et ne
> tiendront compte que de l'extension minimale indiquée par "inner"/outer".
> Mais on sait déjà que faire un rendu correct avec plusieurs géométries sera
> compliqué
>
> (comme je l'expliquais cela demande une triangulation de la zone entre les
> deux géométries, puis une interpolation linéaire dans chaque triangle, et
> demande de gérer les trous de l'extension minimale "inner" couverts
> entièrement sans trou dans l'extension minimale avec
> "inner_max"/"outer_max", et cela demande une règle de validité : la surface
> de l'extension minimale doit être entièrement incluse dans l'extension
> maximale, mais les deux peuvent se toucher dans le cas où les deux
> contiennent certaines frontières précises, et il n'y aura aucune
> triangulation entre les deux puisque là la surface entre les deux est nulle)
>
> Je pense que ma solution ici (avec un seul tag "fuzzy=*") permet de gérer
> tous les cas les plus tordus, sans devoir recourir à la duplication
> systématique des géométries (ce qui reste possible mais sera exceptionnel
> quand on sait que c'est compliqué à rendre graphiquement) et en préservant
> la compatibilité maximale.
>
>
> Le 24 février 2018 à 16:51, djakk djakk  a écrit :
>
>> Oui c’est fuzzy ! Par contre il faut 2 ou 3 géométries, impossible de
>> mesurer le flou avec un tag fuzzy en mètres, car ça ne sera quasiment
>> jamais un disque régulier autour d’un point, ou une enveloppe de largeur
>> identique partout autour d’un polygone.
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 15:54, Philippe Verdy  a
>> écrit :
>>
>>> Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
>>> (en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
>>> "fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et
>>> "fuzzy=no" dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0"
>>> (précis)...
>>> Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment
>>> les noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms
>>> de cols, de sommets, et divers lieux naturels non marqués précisément).
>>> On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des
>>> limites de plages en mer, ou la ligne de côte avec la marge d'incertitude
>>> (là aussi en mètres par défaut).
>>> C'est une propriété purement géométrique (au même sens que les
>>> coordonnées en latitude/longitude, ou l'altitude et l'élévation)
>>>
>>>
>>> Le 24 février 2018 à 15:44, Philippe Verdy  a écrit
>>> :
>>>

 Le 23 février 2018 à 22:13, marc marc  a
 écrit :
 > d’ailleurs est ce que estimated (ou approximatif oui c'est du
 francais Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
 Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
 d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
 délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
 plus de précision (chose impossible ici, on ne peut pas faire mieux).

 Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant,
 pas besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
 nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
 nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
 seuls noeuds d'interconnexion des ways flous avec des frontières précises
 (et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)

 Shéma ultra-simple compatible avec l'existant. Reste ensuite aux
 moteurs de 

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

2 ou trois géométries c'est souvent excessif.

En pratique il suffira d'une seule limite. En avoir plusieurs complique
énormément le rendu (et là ça nécessite des rôles spéciaux).

Le tag "fuzzy=yes/no/distance en mètres" suffira la plupart du temps pour
marquer les chemins (et certains noeuds). Et cela suffit aussi pour taguer
les noeuds isolés dont la précision est floue. (fuzzy=yes n'indique aucune
distance maximale pour le noeud, mais cette distance peut être sur le way
qui contient la distance par défaut applicable tout le long du way, sauf
aux derniers triangles joints à des noeuds "précis" avec "fuzzy=no" ou
indiquant une précision avec fuzzy=distance en mètres".

Si on met plusieurs géométries, au lieu de créer de nouvelles relations
(symptôme de la "relationite aiguë"), là je vois plutôt utiliser les
relations existantes avec des rôles modifiés ("inner"/"outer" deviennent
"inner_max"/"outer_max" pour que ces extensions maximales puissent être
facilement ignorées par les rendus qui ne savent pas ce que c'est et ne
tiendront compte que de l'extension minimale indiquée par "inner"/outer".
Mais on sait déjà que faire un rendu correct avec plusieurs géométries sera
compliqué

(comme je l'expliquais cela demande une triangulation de la zone entre les
deux géométries, puis une interpolation linéaire dans chaque triangle, et
demande de gérer les trous de l'extension minimale "inner" couverts
entièrement sans trou dans l'extension minimale avec
"inner_max"/"outer_max", et cela demande une règle de validité : la surface
de l'extension minimale doit être entièrement incluse dans l'extension
maximale, mais les deux peuvent se toucher dans le cas où les deux
contiennent certaines frontières précises, et il n'y aura aucune
triangulation entre les deux puisque là la surface entre les deux est nulle)

Je pense que ma solution ici (avec un seul tag "fuzzy=*") permet de gérer
tous les cas les plus tordus, sans devoir recourir à la duplication
systématique des géométries (ce qui reste possible mais sera exceptionnel
quand on sait que c'est compliqué à rendre graphiquement) et en préservant
la compatibilité maximale.


Le 24 février 2018 à 16:51, djakk djakk  a écrit :

> Oui c’est fuzzy ! Par contre il faut 2 ou 3 géométries, impossible de
> mesurer le flou avec un tag fuzzy en mètres, car ça ne sera quasiment
> jamais un disque régulier autour d’un point, ou une enveloppe de largeur
> identique partout autour d’un polygone.
>
> djakk
>
>
> Le sam. 24 févr. 2018 à 15:54, Philippe Verdy  a
> écrit :
>
>> Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
>> (en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
>> "fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et
>> "fuzzy=no" dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0"
>> (précis)...
>> Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment
>> les noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms
>> de cols, de sommets, et divers lieux naturels non marqués précisément).
>> On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des
>> limites de plages en mer, ou la ligne de côte avec la marge d'incertitude
>> (là aussi en mètres par défaut).
>> C'est une propriété purement géométrique (au même sens que les
>> coordonnées en latitude/longitude, ou l'altitude et l'élévation)
>>
>>
>> Le 24 février 2018 à 15:44, Philippe Verdy  a écrit :
>>
>>>
>>> Le 23 février 2018 à 22:13, marc marc  a
>>> écrit :
>>> > d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
>>> Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
>>> Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
>>> d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
>>> délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
>>> plus de précision (chose impossible ici, on ne peut pas faire mieux).
>>>
>>> Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant,
>>> pas besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
>>> nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
>>> nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
>>> seuls noeuds d'interconnexion des ways flous avec des frontières précises
>>> (et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)
>>>
>>> Shéma ultra-simple compatible avec l'existant. Reste ensuite aux moteurs
>>> de rendus de prendre en compte "fuzzy=*" pour ne pas tracer des frontières
>>> de façon trop marquée.
>>>
>>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] Usage d'OSM par les services de secours du pays-bas

[Philippe Verdy]

Je suis admiratif sur la façon dont les conducteurs aux Pays-Bas font de
leur mieux pour laisser le passage aux véhicules d'urgence, se parquent sur
les voies d'arrêt d'urgence (en mettant les warnings), n'entrent pas dans
un carrefour même si le feu est vert pour eux, et signalent même les
véhicules devant eux pour leur signaler et faire la même chose. Et tout le
monde respecte ça, il n'y en a pas qui profitent de ce dégagement de la
voie pour doubler une file dans un bouchon et passer devant le véhicule
d'urgence.

Même dans le cas d'une bretelle de sortie où il y a une réduction du nombre
de voies, ils n'hésitent pas à s'arrêter (et allumer leur warning) sur leur
voie, pour ne pas fusionner dans la voie unique qu'ils laissent libre pour
le passage de l'ambulance. La voie d'arrêt d'urgence sur les autoroutes et
voies express est toujours libre pour pouvoir s'y arrêter et laisser le
passage en toute sécurité si nécessaire. Les conducteurs néerlandais sont
prévoyants (hormis le cas d'un seul camion dans la vidéo qui est passé et a
bloqué le passage du véhicule d'urgence, il devait être étourdi mais il
était le seul).

Même les camions et certains véhicules respectent ça et sont équipés pour
certains de feux clignotants spéciaux (à clignotement rapide) pour signaler
au véhicule d'urgence qu'ils ont laissé un passage libre sur la voie qu'ils
ont dégagé (les autres véhicules utilisent au minimum leurs feux "warning"
quand ils manœuvrent pour se ranger).

On n'a pas les même comportements en France, par exemple sur les bandes
d'arrêt d'urgence sur nos autoroutes ou sur les périphériques parisiens ou
nantais (sans toutefois atteindre les sommets de l'imprudence et
l'incivilité qu'on voit en Russie, où nombre de conducteurs plus prudents
ont installé des caméras embarquées avec enregistrement dans leur véhicule
pour faire preuve et témoigner des imprudences des autres : les vidéos
d'accidents en Russie, prises avec ces caméras embarquées, sont terribles
et ça doit être vraiment dangereux pour les véhicules d'urgence d'oser
franchir un feu rouge même s'ils sont "prioritaires" selon la loi).

2018-02-24 10:20 GMT+01:00 David Crochet :

> Bonjour
>
> petite vidéo avec OSM et surcouches : https://youtu.be/_jGGZq6_6hw?t=334
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[djakk djakk]

Oui c’est fuzzy ! Par contre il faut 2 ou 3 géométries, impossible de
mesurer le flou avec un tag fuzzy en mètres, car ça ne sera quasiment
jamais un disque régulier autour d’un point, ou une enveloppe de largeur
identique partout autour d’un polygone.

djakk


Le sam. 24 févr. 2018 à 15:54, Philippe Verdy  a écrit :

> Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
> (en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
> "fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et
> "fuzzy=no" dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0"
> (précis)...
> Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment
> les noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms
> de cols, de sommets, et divers lieux naturels non marqués précisément).
> On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des
> limites de plages en mer, ou la ligne de côte avec la marge d'incertitude
> (là aussi en mètres par défaut).
> C'est une propriété purement géométrique (au même sens que les coordonnées
> en latitude/longitude, ou l'altitude et l'élévation)
>
>
> Le 24 février 2018 à 15:44, Philippe Verdy  a écrit :
>
>>
>> Le 23 février 2018 à 22:13, marc marc  a
>> écrit :
>> > d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
>> Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
>> Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
>> d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
>> délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
>> plus de précision (chose impossible ici, on ne peut pas faire mieux).
>>
>> Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant,
>> pas besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
>> nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
>> nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
>> seuls noeuds d'interconnexion des ways flous avec des frontières précises
>> (et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)
>>
>> Shéma ultra-simple compatible avec l'existant. Reste ensuite aux moteurs
>> de rendus de prendre en compte "fuzzy=*" pour ne pas tracer des frontières
>> de façon trop marquée.
>>
>>
> ___
> 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-es] #Importaciones2018 : Reorganización

[Miguel Sevilla-Callejo]

Muchas gracias,

Estaré atento para ver en qué puedo ayudar.

Sin ir más lejos veo que para Aragón podríamos incluir la base cartográfica
armonizada (BTA) y otros recursos del Instituto Geográfico de Aragón [1] y
otros que están en Aragón Open Data [2] cuyos datos están en Creative
Commons BY 4.0... por lo que necesitaríamos autorización explícita para
usarlos.

[1] http://www.aragon.es/igear
[2] https://opendata.aragon.es/

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-02-24 13:59 GMT+01:00 dcapillae :

> Gracias, Yo_paseopor.
>
> He decidido empezar a trabajar en la reorganización de la página del wiki
> dedicada a fuentes de datos potenciales de España [1], así como de otras
> páginas relacionadas (importaciones, autorizaciones, etc.). Necesitaré
> colaboración de la comunidad para resolver las dudas que me vayan
> surgiendo.
> Utilizaré este hilo en la lista de correo o la página de discusión del wiki
> [2].
>
> Gracias de nuevo.
>
> [1]
> https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_
> potenciales_de_España
> [2]
> https://wiki.openstreetmap.org/wiki/ES_talk:Fuentes_de_
> datos_potenciales_de_Espa%C3%B1a#Reorganizaci.C3.B3n_de_la_wiki
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it-lazio] Lunedì 26 febbraio ci vediamo?

[flaminiatumino]

Per me va bene a La strada.
A che ora?
Flaminia 

Sent from my iPhone

> On 24 Feb 2018, at 15:07, Martin Koppenhoefer  wrote:
> 
> Anch’io ci sono. Per il luogo propongo lo spazio aula/studio “upstairs” del 
> centro sociale la strada. È libero lunedì e si trova qui:
> https://www.openstreetmap.org/way/77683597
> 
> Che ne dite? Da bere si potrebbe prendere al bar della strada.
> 
> Ciao, Martin 
> 
> ___
> Talk-it-lazio mailing list
> Talk-it-lazio@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-lazio
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

In addition of the « traffic » tag, there could be the « importance » tag
(already use for railways - regional or national), with 5 values :
neighbourhood, city, regional, national, continental.

The example of the trunk road around Island : traffic=low,
importance=national :)

djakk


Le sam. 24 févr. 2018 à 14:22, djakk djakk  a écrit :

> Yes, we should be able to tag secondary motorway or secondary motorroads. (
> https://www.openstreetmap.org/#map=15/48.8719/2.4496 - https
> ://www.openstreetmap.org/#map=17/48.57211/-2.82279)
>
> djakk
>
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Francesco Pelullo]

Il 24 feb 2018 3:08 PM, "Alessandro Sarretta" 
ha scritto:



Dopodiché la funzionalità di upload automatico si sblocca.


Esatto. E se hai fatto casino, non vieni semplicemente bannato, vieni
retrocesso a livello inferiore a quello dei nuovi utenti.

In questo modo, consegui un risultato importante:
se ti retrocedono, ti rode perché devi ricominciare tutto da capo prima di
poter fare casino di nuovo. E se sei veramente stronzo e tieni duro e
riesci alla fine ad avere i diritti per fare casino, al massimo cancelli
una strada, non una relazione, perché per fare quello ti serve un ranking
di un anno. Fine dei vandali.

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
(en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
"fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et "fuzzy=no"
dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0" (précis)...
Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment les
noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms de
cols, de sommets, et divers lieux naturels non marqués précisément).
On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des limites
de plages en mer, ou la ligne de côte avec la marge d'incertitude (là aussi
en mètres par défaut).
C'est une propriété purement géométrique (au même sens que les coordonnées
en latitude/longitude, ou l'altitude et l'élévation)


Le 24 février 2018 à 15:44, Philippe Verdy  a écrit :

>
> Le 23 février 2018 à 22:13, marc marc  a écrit
> :
> > d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
> Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
> Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
> d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
> délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
> plus de précision (chose impossible ici, on ne peut pas faire mieux).
>
> Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant,
> pas besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
> nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
> nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
> seuls noeuds d'interconnexion des ways flous avec des frontières précises
> (et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)
>
> Shéma ultra-simple compatible avec l'existant. Reste ensuite aux moteurs
> de rendus de prendre en compte "fuzzy=*" pour ne pas tracer des frontières
> de façon trop marquée.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Le 23 février 2018 à 22:13, marc marc  a écrit :
> d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
plus de précision (chose impossible ici, on ne peut pas faire mieux).

Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant, pas
besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
seuls noeuds d'interconnexion des ways flous avec des frontières précises
(et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)

Shéma ultra-simple compatible avec l'existant. Reste ensuite aux moteurs de
rendus de prendre en compte "fuzzy=*" pour ne pas tracer des frontières de
façon trop marquée.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Le 24 février 2018 à 01:30, Jérôme Amagat  a écrit
:

> Placer un tag sur le way qui fait parti de la relation : si le way sert à
> plusieurs choses comment savoir que le tag sert à cette relation et pas à
> autre chose.
>

Il est complètement proscrit dans OSM d'utiliser le même objet  OSM pour
deux objets qui ne sont pas EXACTEMENT placés de la même façon. Donc non,
ce way ne devra pas servir à autre chose de précis qui devra être tracé
séparément sans ce tag. Le way pourrait en revanche servir à plusieurs
relations imprécises limitrophes l'une de l'autre (quand l'appartenance
d'un lieu à une est exclusive de l'autre).

Si les deux zones limitrophes sont imprécises mais peuvent se recouvrir
partiellement (on ne sait pas de combien, chacune aura ses propres ways
imprécis, avec une surface non nulle incluse dans les deux relations entre
ces ways de chacune).

Je suis persuadé que c'est bien sur le way qu'il faut taguer ça (ce qui
permet d'avoir une relation ayant des ways précis et d'autres flous, les
ways flous pouvant commencer ou se terminer par un point précis pour se
connecter aux ways flous, ces noeuds devraient avoir un tag indiquant
qu'ils sont précis, afin de ne pas avoir non plus à taguer tous les autres
noeuds flous des frontières floues).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Alessandro Sarretta]

Ciao a tutti,
mi aggancio solamente alla questione che riguarda da una parte 
migliorare la qualità dell'editing, dall'altra diminuire i vandalismi.


On 24/02/2018 14:25, Francesco Pelullo wrote:

Basterebbe attribuire un rank a ciascun utente, basato sulla esperienza.

Tipo, utente appena registrato? Ranking=1
Utente bannato? Ranking = 0
Utente con 100 edit senza commenti negativi? Ranking 10
Eccetera

Poi definire dei criteri:
ranking= 0 >>> nessun accesso,
ranking = 1 >>> può inserire nuove features nella chiave highway, 
building ... ma non può creare limiti amministrativi, landuse e 
costline, non può modificare quello che c'è, non può cancellare niente

ranking = 100 >>> un gradino in più
La proposta di Francesco mi sembra molto sensata e provo a specificarla 
ulteriormente.
Un mini tutorial/corso proposto/richiesto ai nuovi contributori 
sicuramente è utile, ma potrebbe non intercettare errori banali e vandali.
Se invece si attuasse un ranking in funzione del numero di edit (o altri 
badges di riconoscimento anche forniti dalla comunità), questo potrebbe 
venire immediatamente applicato in vari contesti.
Ad esempio la validazione obbligatoria dei changeset prima 
dell'inclusione in OSM (irrealizzabile in generale) potrebbe credo 
realisticamente essere applicata per i nuovi utenti fino al 
raggiungimento di, che ne so, 10, 20 edits? Per il lavoro di validazione 
probabilmente si potrebbe richiedere un ranking x. Dopodiché la 
funzionalità di upload automatico si sblocca. Se si potesse aggiungere 
la possibilità di valutare negativamente un changeset, l'utente che ne 
accumula più di x tornerebbe a vedere i suoi edit validati prima del 
caricamento.
Anche il lavoro del DWG sarebbe mi pare agevolato se, oltre alla 
possibilità di blocco, ci fosse anche la possibilità di "retrocedere" un 
utente al livello di validazione.
Ovviamente questo comporta un carico di lavoro in più per qualcuno, ma 
mi pare che un lavoro di pre-validazione sia in definitiva più efficace 
e meno frustrante della modalità di commento/avviso/interazione con 
DWG/blocchi vari/... attuale. Questo lavoro di post validazione lo si fa 
già in effetti, ma è molto più difficile...
Il lavoro di validazione potrebbe anche essere organizzato con strumenti 
tipo un "validation manager" basato su principi simili al task manager.


Chiedo ai più esperti e storici... immagino che questo tipo di discorsi 
sia già stato affrontato in passato. Ci sono motivi per cui non si possa 
cercare di riportarlo in alto nelle priorità della comunitàinternazionale?


m2c

Ale

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-it-lazio] Lunedì 26 febbraio ci vediamo?

[Martin Koppenhoefer]

Anch’io ci sono. Per il luogo propongo lo spazio aula/studio “upstairs” del 
centro sociale la strada. È libero lunedì e si trova qui:
https://www.openstreetmap.org/way/77683597

Che ne dite? Da bere si potrebbe prendere al bar della strada.

Ciao, Martin 

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

Re: [Talk-it-lazio] Lunedì 26 febbraio ci vediamo?

[Marcello Pelato]

Allora ci sei! :-)Evviva, io posso essere presente.Per il dove non ho problemi.Il 24 feb 2018 1:03 PM, Flaminia Tumino  ha scritto:Ciao a tutti,come è andata alla conferenza di OSM?Ci vediamo lunedì sera al solito pub? Chi ci sta?Flaminia Mail priva di virus. www.avast.com 		

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[paolo bubici]

Anche se con finalità differenti si potrebbe utilizzare il progetto di Osm
Streak

http://streak.osmz.ru/

Bubix

Il Sab 24 Feb 2018, 14:26 Francesco Pelullo  ha
scritto:

>
>
> Il 24 feb 2018 9:58 AM, "Alessandro"  ha scritto:
>
> Ciao Aury,
> questa procedura potrebbe eliminare i bot ma non avrebbe effetto nè su
> molti vandali (su qualcuno sì perchè si scoccerebbe) e aiuterebbe poco chi
> commette errori per inesperienza.
> Sul lato implementazione poi ci sarebbe da capire come attuare la cosa, ma
> almeno discuterne è già un primo passo.
>
>
> Basterebbe attribuire un rank a ciascun utente, basato sulla esperienza.
>
> Tipo, utente appena registrato? Ranking=1
> Utente bannato? Ranking = 0
> Utente con 100 edit senza commenti negativi? Ranking 10
> Eccetera
>
> Poi definire dei criteri:
> ranking= 0 >>> nessun accesso,
> ranking = 1 >>> può inserire nuove features nella chiave highway, building
> ... ma non può creare limiti amministrativi, landuse e costline, non può
> modificare quello che c'è, non può cancellare niente
> ranking = 100 >>> un gradino in più
>
> Ciao
> /niubii/
>
>
>
>
> ___
> 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] Why OpenStreetMap is in Serious Trouble

[Francesco Pelullo]

Il 24 feb 2018 9:58 AM, "Alessandro"  ha scritto:

Ciao Aury,
questa procedura potrebbe eliminare i bot ma non avrebbe effetto nè su
molti vandali (su qualcuno sì perchè si scoccerebbe) e aiuterebbe poco chi
commette errori per inesperienza.
Sul lato implementazione poi ci sarebbe da capire come attuare la cosa, ma
almeno discuterne è già un primo passo.


Basterebbe attribuire un rank a ciascun utente, basato sulla esperienza.

Tipo, utente appena registrato? Ranking=1
Utente bannato? Ranking = 0
Utente con 100 edit senza commenti negativi? Ranking 10
Eccetera

Poi definire dei criteri:
ranking= 0 >>> nessun accesso,
ranking = 1 >>> può inserire nuove features nella chiave highway, building
... ma non può creare limiti amministrativi, landuse e costline, non può
modificare quello che c'è, non può cancellare niente
ranking = 100 >>> un gradino in più

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Yes, we should be able to tag secondary motorway or secondary motorroads. (
https://www.openstreetmap.org/#map=15/48.8719/2.4496 -
https://www.openstreetmap.org/#map=17/48.57211/-2.82279)

djakk



Le sam. 24 févr. 2018 à 13:34, Fernando Trebien 
a écrit :

> On Sat, Feb 24, 2018 at 7:16 AM, Matej Lieskovský
>  wrote:
> > One last observation:
> > Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and
> Slovakia
> > all use a similar system where highway=trunk is "motorway-like", with
> trunk
> > either implying motorroad status, or being a prerequisite for it.
>
> In Brazil, the highways that would most closely correspond to the idea
> of a motorroad are actually considered inferior because they lack
> shoulders and are, thus, less safe for travel. They are usually built
> like that to cut costs, not as an ultimately desirable design, so they
> tend to be minor, not major routes.
>
> TagInfo [1] also tells me that there are many motorroads in OSM that
> are primary, not trunk. Probably not in the countries you mentioned,
> but they seem to exist in the UK and in Norway (where there may even
> be some motorroads classified as secondary) [2].
>
> [1] https://taginfo.openstreetmap.org/tags/motorroad=yes#combinations
> [2] https://wiki.openstreetmap.org/wiki/Key:motorroad
>
> > On 24 February 2018 at 11:08, Matej Lieskovský <
> lieskovsky.ma...@gmail.com>
> > wrote:
> >>
> >> 1)
> >> Trunk in Czechia is "motorway-like".
> >> Feel free to document local conventions here:
> >> https://wiki.openstreetmap.org/wiki/Highway_classes
> >> Also, see this:
> >>
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence
> >>
> >> 2)
> >> Highway classification is not really a measurable thing. I'd compare it
> to
> >> how admin_level works. There is some equivalence, but everyone
> understands
> >> that admin_level=4 means something slightly different in Czechia and in
> the
> >> US.
> >>
> >> I'd be very careful about global definitions as we might easily end up
> >> with entire countries without even a highway=primary. I mean, how can
> Brazil
> >> have unpaved trunk roads? Does Iceland get to keep its trunk road when
> it
> >> has only one city of more than 35000 inhabitants? Do we get to keep
> trunk
> >> roads when there are several cities in China with more people than the
> >> entire Czech Republic? By similar logic the outer border of Czech
> Republic
> >> should be approximately admin_level=4 (to match US states) and trust me
> that
> >> EU integration is not yet at the point where that would be acceptable.
> :)
> >>
> >> Let's get the wiki filled in, we might be wiser afterwards.
> >>
> >> @djakk: Thanks for making the discussion a little more organized.
> >>
> >> On 24 February 2018 at 10:30, djakk djakk 
> wrote:
> >>>
> >>> There is 2 « independant » things in the debate :
> >>> 1) trunk definition - what is a trunk, a motorway-like road - based on
> >>> physical characteristics- or a super-primary road - based on the
> importance
> >>> ?
> >>> 2) wordwilde trunk definition ? - should we have the same definition
> all
> >>> over the world of what is highway= trunk ? (value that are
> country-dependant
> >>> are not that common, aren’t they ?)
> >>>
> >>> djakk
> >>>
> >>>
> >>> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský
> >>>  a écrit :
> 
>  1) If you want to look at a professional map of Czechia, I'd recommend
>  www.mapy.cz over google maps as that is the most used and far more
> detailed
>  map.
>  2) I agree that the discontinuities are ugly, but they reflect the
> state
>  on the ground. That section around Sulec is a trunk instead of a
> primary due
>  to the fact that it is a section of future motorway built to motorway
>  standard. While your system heavily preferences "importance" of
> roads, our
>  local system reflects reality. Declaring the entire road from Pilsen
> to
>  České Budějovice as trunk due to its importance loses the information
> that
>  there is a section that was built as a motorway link to Písek. I can
> already
>  tell that the road is important because it links Pilsen and České
> Budějovice
>  (by looking at the map), but I also want to know that it was built as
> a
>  primary road and not as a trunk - that means that I'm going to expect
> more
>  single-level junctions and only two lanes for most of the way.
> 
>  I agree, our trunk roads are a little fuzzy on their definition, but
>  elevating random primary roads to trunk is a loss of data for us.
> Touching
>  anything else than reclassifying primary to trunk et vice versa will
>  certainly be considered as vandalism in Czechia.
> 
>  You are demonstrating that you can guess the road class from other
> data.
>  I think it's cute, but does not match on-the-ground data in countries
> 

Re: [Talk-es] #Importaciones2018 : Reorganización

[dcapillae]

Gracias, Yo_paseopor.

He decidido empezar a trabajar en la reorganización de la página del wiki
dedicada a fuentes de datos potenciales de España [1], así como de otras
páginas relacionadas (importaciones, autorizaciones, etc.). Necesitaré
colaboración de la comunidad para resolver las dudas que me vayan surgiendo.
Utilizaré este hilo en la lista de correo o la página de discusión del wiki
[2].

Gracias de nuevo.

[1]
https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_potenciales_de_España
[2]
https://wiki.openstreetmap.org/wiki/ES_talk:Fuentes_de_datos_potenciales_de_Espa%C3%B1a#Reorganizaci.C3.B3n_de_la_wiki



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Sat, Feb 24, 2018 at 7:16 AM, Matej Lieskovský
 wrote:
> One last observation:
> Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and Slovakia
> all use a similar system where highway=trunk is "motorway-like", with trunk
> either implying motorroad status, or being a prerequisite for it.

In Brazil, the highways that would most closely correspond to the idea
of a motorroad are actually considered inferior because they lack
shoulders and are, thus, less safe for travel. They are usually built
like that to cut costs, not as an ultimately desirable design, so they
tend to be minor, not major routes.

TagInfo [1] also tells me that there are many motorroads in OSM that
are primary, not trunk. Probably not in the countries you mentioned,
but they seem to exist in the UK and in Norway (where there may even
be some motorroads classified as secondary) [2].

[1] https://taginfo.openstreetmap.org/tags/motorroad=yes#combinations
[2] https://wiki.openstreetmap.org/wiki/Key:motorroad

> On 24 February 2018 at 11:08, Matej Lieskovský 
> wrote:
>>
>> 1)
>> Trunk in Czechia is "motorway-like".
>> Feel free to document local conventions here:
>> https://wiki.openstreetmap.org/wiki/Highway_classes
>> Also, see this:
>> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence
>>
>> 2)
>> Highway classification is not really a measurable thing. I'd compare it to
>> how admin_level works. There is some equivalence, but everyone understands
>> that admin_level=4 means something slightly different in Czechia and in the
>> US.
>>
>> I'd be very careful about global definitions as we might easily end up
>> with entire countries without even a highway=primary. I mean, how can Brazil
>> have unpaved trunk roads? Does Iceland get to keep its trunk road when it
>> has only one city of more than 35000 inhabitants? Do we get to keep trunk
>> roads when there are several cities in China with more people than the
>> entire Czech Republic? By similar logic the outer border of Czech Republic
>> should be approximately admin_level=4 (to match US states) and trust me that
>> EU integration is not yet at the point where that would be acceptable. :)
>>
>> Let's get the wiki filled in, we might be wiser afterwards.
>>
>> @djakk: Thanks for making the discussion a little more organized.
>>
>> On 24 February 2018 at 10:30, djakk djakk  wrote:
>>>
>>> There is 2 « independant » things in the debate :
>>> 1) trunk definition - what is a trunk, a motorway-like road - based on
>>> physical characteristics- or a super-primary road - based on the importance
>>> ?
>>> 2) wordwilde trunk definition ? - should we have the same definition all
>>> over the world of what is highway= trunk ? (value that are country-dependant
>>> are not that common, aren’t they ?)
>>>
>>> djakk
>>>
>>>
>>> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský
>>>  a écrit :

 1) If you want to look at a professional map of Czechia, I'd recommend
 www.mapy.cz over google maps as that is the most used and far more detailed
 map.
 2) I agree that the discontinuities are ugly, but they reflect the state
 on the ground. That section around Sulec is a trunk instead of a primary 
 due
 to the fact that it is a section of future motorway built to motorway
 standard. While your system heavily preferences "importance" of roads, our
 local system reflects reality. Declaring the entire road from Pilsen to
 České Budějovice as trunk due to its importance loses the information that
 there is a section that was built as a motorway link to Písek. I can 
 already
 tell that the road is important because it links Pilsen and České 
 Budějovice
 (by looking at the map), but I also want to know that it was built as a
 primary road and not as a trunk - that means that I'm going to expect more
 single-level junctions and only two lanes for most of the way.

 I agree, our trunk roads are a little fuzzy on their definition, but
 elevating random primary roads to trunk is a loss of data for us. Touching
 anything else than reclassifying primary to trunk et vice versa will
 certainly be considered as vandalism in Czechia.

 You are demonstrating that you can guess the road class from other data.
 I think it's cute, but does not match on-the-ground data in countries where
 road classification is well-defined.

 Look, I've spent a lot of time on this and I have better things to do.
 Fill in the info for your regions on the wiki and then we can see what we
 can do. Until then, bear in mind that "harmonising" European roads will
 likely get you banned. I don't want to sound like I'm threatening you, but
 I've probably spent all the time I'm willing to spend on arguing with some
 random person who wants to break our local road 

Re: [OSRM-talk] OSRM v5.16.0 Release

[Richard Fairhurst]

Chau Nguyen wrote:

### Maneuver Override Relations:

Sometimes road geometries of complicated intersections do not give enough
information on how a suitable guidance should look like. OSRM is now
supporting the `maneuver override` tag in OSM to detect such intersections
and choose better guidance. Read more about the `maneuver override` tag
here:
https://github.com/Project-OSRM/osrm-backend/wiki/Maneuver-override-tag


Looks great!

The lingua franca of OSM is British English, though, so that should 
probably be "manoeuvre".


http://grammarist.com/spelling/maneuver-manoeuvre/

cheers
Richard

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Sat, Feb 24, 2018 at 7:08 AM, Matej Lieskovský
 wrote:
> I mean, how can Brazil have
> unpaved trunk roads? Does Iceland get to keep its trunk road when it has
> only one city of more than 35000 inhabitants? Do we get to keep trunk roads
> when there are several cities in China with more people than the entire
> Czech Republic? By similar logic the outer border of Czech Republic should
> be approximately admin_level=4 (to match US states) and trust me that EU
> integration is not yet at the point where that would be acceptable. :)

Unpaved trunk roads are not so unexpected [1][2].

place=* is defined differently in many countries to compensate for
differences in population density. That would solve the problems you
just mentioned. For example, in Russia [3], they define it this way:
- place=city: settlement of 100k people, or provincial capital with 40k people
- place=town: urban settlement of 5k people, rural settlement of 8k
people, or municipal district of 2k (if urban) or 4k (if not urban)
people

I didn't find the definition for Iceland, but currently the capital is
mapped as place=city and all settlements with 1k people or more are
place=town. All of those settlements are connected by highway=primary,
which is the level that would connect them according to my proposal.
Even though the Ring Road is entirely mapped as a trunk, its structure
is not the same everywhere; it is even unpaved in some sections
[4][5], but the classification doesn't change as a result of those
changes in structure. And the local community could have voted to make
the Ring Road an explicit exception to the general rule. But it would
also be interesting to discuss what makes the Ring Road important,
perhaps the reasons would apply elsewhere. The most populous
settlement that is not connected by the Ring Road is Ísafjörður, with
3.7k inhabitants and the 13th most populous in Iceland. This may
indicate an interesting idea: the Ring Road may be important because
it connects the majority of people in the country [6], regardless of
whether these people are concentrated in few large settlements or
spread over a vast area. How about Czechia? Looking at the population
distribution [7], the map that I generated seems to closely follow
population distribution (probably a result of planning), and I could
say that it makes sense to add other regional capitals to the same set
of cities (such as Karlovy Vary and Zlín).

mapy.cz uses OSM data, so I believe it does not count in this
discussion as an alternative approach to highway classification.

[1] https://github.com/gravitystorm/openstreetmap-carto/issues/110
[2] https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Trunk
[3] https://wiki.openstreetmap.org/wiki/RU:Key:place
[4] 
https://www.google.com.br/maps/@64.7966139,-14.5148196,3a,75y,96.06h,87.07t/data=!3m6!1e1!3m4!1s8fD89Ax72Y9lqw9RkXcyUg!2e0!7i13312!8i6656
[5] https://en.wikipedia.org/wiki/Route_1_(Iceland)
[6] http://i.imgur.com/uFFiPsz.png
[7] 
https://www.mapmania.org/map/64667/czech_republic_czechia_population_density_2007

> On 24 February 2018 at 10:30, djakk djakk  wrote:
>>
>> There is 2 « independant » things in the debate :
>> 1) trunk definition - what is a trunk, a motorway-like road - based on
>> physical characteristics- or a super-primary road - based on the importance
>> ?
>> 2) wordwilde trunk definition ? - should we have the same definition all
>> over the world of what is highway= trunk ? (value that are country-dependant
>> are not that common, aren’t they ?)
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský
>>  a écrit :
>>>
>>> 1) If you want to look at a professional map of Czechia, I'd recommend
>>> www.mapy.cz over google maps as that is the most used and far more detailed
>>> map.
>>> 2) I agree that the discontinuities are ugly, but they reflect the state
>>> on the ground. That section around Sulec is a trunk instead of a primary due
>>> to the fact that it is a section of future motorway built to motorway
>>> standard. While your system heavily preferences "importance" of roads, our
>>> local system reflects reality. Declaring the entire road from Pilsen to
>>> České Budějovice as trunk due to its importance loses the information that
>>> there is a section that was built as a motorway link to Písek. I can already
>>> tell that the road is important because it links Pilsen and České Budějovice
>>> (by looking at the map), but I also want to know that it was built as a
>>> primary road and not as a trunk - that means that I'm going to expect more
>>> single-level junctions and only two lanes for most of the way.
>>>
>>> I agree, our trunk roads are a little fuzzy on their definition, but
>>> elevating random primary roads to trunk is a loss of data for us. Touching
>>> anything else than reclassifying primary to trunk et vice versa will
>>> certainly be considered as vandalism in Czechia.
>>>

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/02/18 09:30, djakk djakk wrote:

There is 2 « independant » things in the debate :
1) trunk definition - what is a trunk, a motorway-like road - based on 
physical characteristics- or a super-primary road - based on the 
importance ?
Since the classification initiated from the UK, that is still the base 
and a motorway has restrictions that do not apply to a trunk route such 
as 'no learners'. In addition they were maintained 'nationally' while 
primary roads are a local responsibility. That was been muddied much as 
the idea that trunk routes are faster. For the UK the road structure is 
well defined and it would be nice to get back a rendering with the 
proper colours ( and a selection for that on OSMAND ) ...


2) wordwilde trunk definition ? - should we have the same definition all 
over the world of what is highway= trunk ? (value that are 
country-dependant are not that common, aren’t they ?)
Since there are no distinctions in many countries there is no need to 
include truck if there are no such roads in a country, and perhaps for 
'world wide' trunk gets rendered the same as motorway or primary? Only 
local rendering actually benefits from the distinction? Do any countries 
not have motorways at all? Certainly the current default rendering is 
useless for many of us anyway so we have to ue an alternate anyway ...


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

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

Re: [Talk-de] Dt. Kartenstil: Rendern von historic=fort

[Sven Geggus]

Christoph Hormann  wrote:

> Wenn jetzt dort historic=fort (knapp 3000 Verwendungen) gerendert wird, 
> historic=castle mit >37k Verwendungen und einem etablierten, recht gut 
> nach kulturellen und architektonischen Kriterien definierten und auch 
> verbreitet verwendeten Zusatztag (knapp 10k mal) jedoch nicht ist das 
> recht kontraproduktiv.  

Das sehe ich auch so.

Dieses peinliche Playmobil Ritterburg Symbol impliziert halt mehr eine Burg als
irgendwas anderes.

Es besteht nun halt die Gefahr, dass Burgen und Schlösser mit
historic=castle in historic=fort umgetaggt werden.

Die Symbole für Burgen und Schlösser im dt. Stil stammen aus ATKIS, sind
also gar nicht mal so sehr auf Deutschland begrenzt. Ich bräuchte aber halt
eine Lösung für historic=fort um zu versuchen das Ganze upstream als
pull-request einzureichen.

Gruss

Sven

-- 
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[Talk-it-lazio] Lunedì 26 febbraio ci vediamo?

[Flaminia Tumino]

Ciao a tutti,
come è andata alla conferenza di OSM?

Ci vediamo lunedì sera al solito pub? Chi ci sta?

Flaminia


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[r00t]

Ahoj,

> Možná bych do těch statistik mohl přidat možnost přidat ke schránce
> komentář. Ale to bych musel nejprve nastudovat jak funguje oauth ;-)

Tohle by bylo uplne nejlepsi, kdyby se v prehledu dalo ke schrance pridat
komentar. OAuth mozna ani neni potreba, nevim jak moc velka je tu sance ze to
nekdo zacne cilene zneuzivat a skodit, ale CAPTCHA proti botum by mohla stacit.

J.


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

Re: [Talk-it] feedback da FOSS4G-IT 2018

[Alessandro Palmas]

Il 24/02/2018 11:35, Federico Cortese ha scritto:



E' vero, quelli elencati sono degli elementi abbastanza semplici da
aggiungere, che richiedono però la presenza fisica sul posto: d'altra
parte come ho sempre sostenuto il valore aggiunto di OSM è proprio
quello che viene dalla conoscenza diretta dei luoghi (e non dalla
mappatura con le foto satellitari).


Sì, presume la presenza sul posto sebbene con alcune foto è possibile 
contare anche il numero di corsie.


Se in pochi mesi si riuscisse a compiere un discreto progresso in un 
certo numero di comuni si potrebbe portare all'attenzione di VVF e 
Protezione Civile questi progressi e mostrare la facilità di 
contribuzione (aggiungendo qualche challenge a StreetComplete ad 
esempio); in questo modo oltre a maggiore visibilità potremmo avere più 
mappatori che anche da inesperti non creerebbero problemi visto che 
aggiungerebbero principalmente informazioni a elementi già presenti.





Secondo me sarebbe ottima l'idea della "mappatura del mese",
nonostante l'insuccesso del precedente tentativo.
Si potrebbe cominciare ad esempio con i primi tre punti, che
riguardano tutti informazioni di miglioramento del grafo stradale.
Sarebbe divertente introdurre un po' di gamification per invogliare la
mappatura; per esempio fare una "fotografia" della situazione attuale,
magari divisa per comune o per utente, quindi fare il confronto dopo
un mese per stilare una classifica dei migliori risultati.
E' solo un'idea.


Già l'evidenziare l'incremento mensile di questi tag dividendoli per 
regione sarebbe un primo passo. Se poi qualcuno vuole aggiungere altri 
meccanismi, per me benissimo.


Alessandro

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Elena ``of Valhalla'']

On 2018-02-24 at 11:16:22 +0100, Matej Lieskovský wrote:
> One last observation:
> Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and Slovakia
> all use a similar system where highway=trunk is "motorway-like", with trunk
> either implying motorroad status, or being a prerequisite for it.

and Italy too


-- 
Elena ``of Valhalla''

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

Re: [Talk-it] Unione layer

[Gabriele Perrini]

Si ê la seconda ipotesi. Comunque si questo servizio usufruisce sia delle
piste o corsie ciclabili esistenti per le semplici bici sia di ulteriori
percorsi che sono in fase di costruzione e che io ho già progettato su Josm
(ecco perché intendo lavorare offline perché ancora non sono presenti sulla
strada).

Il giorno sab 24 feb 2018 alle 11:22 Volker Schmidt  ha
scritto:

> Mi interessa quello che stai facendo, ma non capisco da quello che scrivi
> come lo vuoi fare.
> Per cominciare che cosa sono i "percorsi di bike sharing" che voi
> utilizzare.
> Le bici del bike sharing possono andare, come tute le bici, su tutte la
> strade aperte alle bici, incluso percorsi riservati a bici.
> Ho intendi le postazioni di bike sharing, alle quali sei vincolato se vuoi
> muoverti con una combinazione di mezzi di trasporto, incluso il bike
> sharing.
> Hai qualche documento di riferimento, dove spieghi i concetti?
> Volker
>
>
> 2018-02-24 10:30 GMT+01:00 Gabriele Perrini :
>
>> Salve a tutti,
>> spero che qualcuno possa aiutarmi!!!
>> Premessa: sto inserendo sull'editor offline JOSM i percorsi di bike
>> sharing che verranno realizzati nel Comune di Palermo.
>> Tranquilli non intendo caricare online su OSM tali dati fin quando non
>> verranno effettivamente realizzati.
>> Allo stato attuale mi accontenterò di lavorare solamente offline.
>> Seguendo il progetto del Comune di Palermo (Piano della mobilità dolce)
>> ho creato su JOSM diversi layer ovvero:
>> 1) Un layer contenente i percorsi
>> 2) Un layer contenente i cicloposteggi
>> 3) Un layer contenente la mappa di Palermo (da Slippy map)
>> Ok, fin qui tutto bene...adesso ho selezionato tutti i tre i layer -->
>> tasto destro --> unisci --> e salvato il tutto in un unico progetto!
>> Adesso, vista l'impossibilità di caricare ad oggi i miei dati online e
>> quindi di poter "sperimentare la tesi" solamente offline, decido di fare
>> delle simulazioni con l'applicazione sempre offline denominata
>> OpenTripPlanner (OTP).
>> Sono arrivato all'obiettivo finale della mia tesi quindi il mio ultimo
>> passaggio verrà basato sull'identificazione di 10 percorsi nei quali
>> verranno calcolati gli spostamenti a piedi, in bici, con tutti i mezzi di
>> trasporto ecc...!
>> Selezionando un punto di partenza e uno di arrivo e calcolando il
>> tragitto "in bici" succede che i percorsi, che avevo precedentemente
>> costruito su JOSM, compaiono a metà nel report finale.
>> Se ad esempio il mio percorso di chiama "A" e io calcolo in percorso
>> lungo A mi dice: Percorri la via NOME VIA e quindi non fa nessun cenno al
>> percorso A.
>> Ecco le Domande che mi/Vi pongo per constatare se magari ho commesso
>> qualche errore su JOSM oppure ho qualche dubbio in merito cioè:
>> 1) Se magari ho unito in maniera errata i miei layer oppure se unendo i
>> layer ad una mappa, la mappa tende ad andare in primo piano rispetto alle
>> linee da me create??
>> 2) Quando ho taggato i percorsi magari ho sbagliato ad inserire la Key e
>> il Value principale --> io ho inserito, ad esempio ipotizzando un percorso
>> denominato A, highway=residental e cycleway=lane cioè io ho identificato la
>> strada e la pista ciclabile al suo interno! Domanda visto: che su OTP i
>> dati sugli altri mezzi pubblici sono già presenti e io devo solamente
>> aggiungere il servizio di bike sharing dovevi mettere ad essere
>> direttamente highway=cycleway cioè inserire solamente dati relativi ai
>> percorsi ciclabili?
>> Spero qualcuno possa aiutarmi, sono agli sgoccioli della mia tesi e
>> sicuramente un piccolo problema non mi permette di analizzare tali dati
>> Grazie per l'attenzione
>> Gabriele
>>
>>
>> ___
>> 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] feedback da FOSS4G-IT 2018

[Federico Cortese]

2018-02-24 10:48 GMT+01:00 Alessandro Palmas :
>
> Come potete vedere, a parte la seconda sulle strade sterrate, sono tutte
> proprietà che più o meno tutti inserirebbero una volta aver raggiunto una
> decente mappatura di base nell’area che normalmente coprono. E sono anche
> caratteristiche che non richiedono conoscenze particolari nelle tecniche e
> nei tag da aggiungere.
>
> E qui mi e vi chiedo: è proprio impensabile riuscire a fare delle
> semplicissime campagna di sensibilizzazione verso la mappatura di semplici
> elementi come questi? Diversi anni fa ci avevamo provato con la mappatura
> del mese o un nome simile ma con scarsissimo successo, tanto che dopo 4 mesi
> fu abbandonata.

E' vero, quelli elencati sono degli elementi abbastanza semplici da
aggiungere, che richiedono però la presenza fisica sul posto: d'altra
parte come ho sempre sostenuto il valore aggiunto di OSM è proprio
quello che viene dalla conoscenza diretta dei luoghi (e non dalla
mappatura con le foto satellitari).
Secondo me sarebbe ottima l'idea della "mappatura del mese",
nonostante l'insuccesso del precedente tentativo.
Si potrebbe cominciare ad esempio con i primi tre punti, che
riguardano tutti informazioni di miglioramento del grafo stradale.
Sarebbe divertente introdurre un po' di gamification per invogliare la
mappatura; per esempio fare una "fotografia" della situazione attuale,
magari divisa per comune o per utente, quindi fare il confronto dopo
un mese per stilare una classifica dei migliori risultati.
E' solo un'idea.

Ciao,
Federico

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

Re: [Talk-it] Unione layer

[Volker Schmidt]

Mi interessa quello che stai facendo, ma non capisco da quello che scrivi
come lo vuoi fare.
Per cominciare che cosa sono i "percorsi di bike sharing" che voi
utilizzare.
Le bici del bike sharing possono andare, come tute le bici, su tutte la
strade aperte alle bici, incluso percorsi riservati a bici.
Ho intendi le postazioni di bike sharing, alle quali sei vincolato se vuoi
muoverti con una combinazione di mezzi di trasporto, incluso il bike
sharing.
Hai qualche documento di riferimento, dove spieghi i concetti?
Volker


2018-02-24 10:30 GMT+01:00 Gabriele Perrini :

> Salve a tutti,
> spero che qualcuno possa aiutarmi!!!
> Premessa: sto inserendo sull'editor offline JOSM i percorsi di bike
> sharing che verranno realizzati nel Comune di Palermo.
> Tranquilli non intendo caricare online su OSM tali dati fin quando non
> verranno effettivamente realizzati.
> Allo stato attuale mi accontenterò di lavorare solamente offline.
> Seguendo il progetto del Comune di Palermo (Piano della mobilità dolce) ho
> creato su JOSM diversi layer ovvero:
> 1) Un layer contenente i percorsi
> 2) Un layer contenente i cicloposteggi
> 3) Un layer contenente la mappa di Palermo (da Slippy map)
> Ok, fin qui tutto bene...adesso ho selezionato tutti i tre i layer -->
> tasto destro --> unisci --> e salvato il tutto in un unico progetto!
> Adesso, vista l'impossibilità di caricare ad oggi i miei dati online e
> quindi di poter "sperimentare la tesi" solamente offline, decido di fare
> delle simulazioni con l'applicazione sempre offline denominata
> OpenTripPlanner (OTP).
> Sono arrivato all'obiettivo finale della mia tesi quindi il mio ultimo
> passaggio verrà basato sull'identificazione di 10 percorsi nei quali
> verranno calcolati gli spostamenti a piedi, in bici, con tutti i mezzi di
> trasporto ecc...!
> Selezionando un punto di partenza e uno di arrivo e calcolando il tragitto
> "in bici" succede che i percorsi, che avevo precedentemente costruito su
> JOSM, compaiono a metà nel report finale.
> Se ad esempio il mio percorso di chiama "A" e io calcolo in percorso lungo
> A mi dice: Percorri la via NOME VIA e quindi non fa nessun cenno al
> percorso A.
> Ecco le Domande che mi/Vi pongo per constatare se magari ho commesso
> qualche errore su JOSM oppure ho qualche dubbio in merito cioè:
> 1) Se magari ho unito in maniera errata i miei layer oppure se unendo i
> layer ad una mappa, la mappa tende ad andare in primo piano rispetto alle
> linee da me create??
> 2) Quando ho taggato i percorsi magari ho sbagliato ad inserire la Key e
> il Value principale --> io ho inserito, ad esempio ipotizzando un percorso
> denominato A, highway=residental e cycleway=lane cioè io ho identificato la
> strada e la pista ciclabile al suo interno! Domanda visto: che su OTP i
> dati sugli altri mezzi pubblici sono già presenti e io devo solamente
> aggiungere il servizio di bike sharing dovevi mettere ad essere
> direttamente highway=cycleway cioè inserire solamente dati relativi ai
> percorsi ciclabili?
> Spero qualcuno possa aiutarmi, sono agli sgoccioli della mia tesi e
> sicuramente un piccolo problema non mi permette di analizzare tali dati
> Grazie per l'attenzione
> Gabriele
>
>
> ___
> 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] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

One last observation:
Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and Slovakia
all use a similar system where highway=trunk is "motorway-like", with trunk
either implying motorroad status, or being a prerequisite for it.

On 24 February 2018 at 11:08, Matej Lieskovský 
wrote:

> 1)
> Trunk in Czechia is "motorway-like".
> Feel free to document local conventions here: https://wiki.
> openstreetmap.org/wiki/Highway_classes
> Also, see this: https://wiki.openstreetmap.org/wiki/Tag:
> highway%3Dtrunk#International_equivalence
>
> 2)
> Highway classification is not really a measurable thing. I'd compare it to
> how admin_level works. There is some equivalence, but everyone understands
> that admin_level=4 means something slightly different in Czechia and in the
> US.
>
> I'd be very careful about global definitions as we might easily end up
> with entire countries without even a highway=primary. I mean, how can
> Brazil have unpaved trunk roads? Does Iceland get to keep its trunk road
> when it has only one city of more than 35000 inhabitants? Do we get to keep
> trunk roads when there are several cities in China with more people than
> the entire Czech Republic? By similar logic the outer border of Czech
> Republic should be approximately admin_level=4 (to match US states) and
> trust me that EU integration is not yet at the point where that would be
> acceptable. :)
>
> Let's get the wiki filled in, we might be wiser afterwards.
>
> @djakk: Thanks for making the discussion a little more organized.
>
> On 24 February 2018 at 10:30, djakk djakk  wrote:
>
>> There is 2 « independant » things in the debate :
>> 1) trunk definition - what is a trunk, a motorway-like road - based on
>> physical characteristics- or a super-primary road - based on the importance
>> ?
>> 2) wordwilde trunk definition ? - should we have the same definition all
>> over the world of what is highway= trunk ? (value that are
>> country-dependant are not that common, aren’t they ?)
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský <
>> lieskovsky.ma...@gmail.com> a écrit :
>>
>>> 1) If you want to look at a professional map of Czechia, I'd recommend
>>> www.mapy.cz over google maps as that is the most used and far more
>>> detailed map.
>>> 2) I agree that the discontinuities are ugly, but they reflect the state
>>> on the ground. That section around Sulec is a trunk instead of a primary
>>> due to the fact that it is a section of future motorway built to motorway
>>> standard. While your system heavily preferences "importance" of roads, our
>>> local system reflects reality. Declaring the entire road from Pilsen to
>>> České Budějovice as trunk due to its importance loses the information that
>>> there is a section that was built as a motorway link to Písek. I can
>>> already tell that the road is important because it links Pilsen and České
>>> Budějovice (by looking at the map), but I also want to know that it was
>>> built as a primary road and not as a trunk - that means that I'm going to
>>> expect more single-level junctions and only two lanes for most of the way.
>>>
>>> I agree, our trunk roads are a little fuzzy on their definition, but
>>> elevating random primary roads to trunk is a loss of data for us. Touching
>>> anything else than reclassifying primary to trunk et vice versa will
>>> certainly be considered as vandalism in Czechia.
>>>
>>> You are demonstrating that you can guess the road class from other data.
>>> I think it's cute, but does not match on-the-ground data in countries where
>>> road classification is well-defined.
>>>
>>> Look, I've spent a lot of time on this and I have better things to do.
>>> Fill in the info for your regions on the wiki and then we can see what we
>>> can do. Until then, bear in mind that "harmonising" European roads will
>>> likely get you banned. I don't want to sound like I'm threatening you, but
>>> I've probably spent all the time I'm willing to spend on arguing with some
>>> random person who wants to break our local road classification system
>>> "because it will look nicer".
>>>
>>> On 24 February 2018 at 07:59, djakk djakk  wrote:
>>>
 Yes, but this rendering does not change when a road crosses a border ^^

 djakk


 Le sam. 24 févr. 2018 à 05:43, JB  a écrit :

> There is something I don't get.
> Draw primary the same color as trunk and you have no more «
> discontinuity »?
> In France, some commercial map (the most sold, I think) use a different
> rendering for trunk and primary, because you drive faster on trunks. I
> like it, I think they like it, because they have been using this
> rendering for decades.
> JB.
>
> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
> > As an exercise (and I'm curious about your thoughts on this), I found
> > the main routes between 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

1)
Trunk in Czechia is "motorway-like".
Feel free to document local conventions here:
https://wiki.openstreetmap.org/wiki/Highway_classes
Also, see this:
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence

2)
Highway classification is not really a measurable thing. I'd compare it to
how admin_level works. There is some equivalence, but everyone understands
that admin_level=4 means something slightly different in Czechia and in the
US.

I'd be very careful about global definitions as we might easily end up with
entire countries without even a highway=primary. I mean, how can Brazil
have unpaved trunk roads? Does Iceland get to keep its trunk road when it
has only one city of more than 35000 inhabitants? Do we get to keep trunk
roads when there are several cities in China with more people than the
entire Czech Republic? By similar logic the outer border of Czech Republic
should be approximately admin_level=4 (to match US states) and trust me
that EU integration is not yet at the point where that would be acceptable.
:)

Let's get the wiki filled in, we might be wiser afterwards.

@djakk: Thanks for making the discussion a little more organized.

On 24 February 2018 at 10:30, djakk djakk  wrote:

> There is 2 « independant » things in the debate :
> 1) trunk definition - what is a trunk, a motorway-like road - based on
> physical characteristics- or a super-primary road - based on the importance
> ?
> 2) wordwilde trunk definition ? - should we have the same definition all
> over the world of what is highway= trunk ? (value that are
> country-dependant are not that common, aren’t they ?)
>
> djakk
>
>
> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský <
> lieskovsky.ma...@gmail.com> a écrit :
>
>> 1) If you want to look at a professional map of Czechia, I'd recommend
>> www.mapy.cz over google maps as that is the most used and far more
>> detailed map.
>> 2) I agree that the discontinuities are ugly, but they reflect the state
>> on the ground. That section around Sulec is a trunk instead of a primary
>> due to the fact that it is a section of future motorway built to motorway
>> standard. While your system heavily preferences "importance" of roads, our
>> local system reflects reality. Declaring the entire road from Pilsen to
>> České Budějovice as trunk due to its importance loses the information that
>> there is a section that was built as a motorway link to Písek. I can
>> already tell that the road is important because it links Pilsen and České
>> Budějovice (by looking at the map), but I also want to know that it was
>> built as a primary road and not as a trunk - that means that I'm going to
>> expect more single-level junctions and only two lanes for most of the way.
>>
>> I agree, our trunk roads are a little fuzzy on their definition, but
>> elevating random primary roads to trunk is a loss of data for us. Touching
>> anything else than reclassifying primary to trunk et vice versa will
>> certainly be considered as vandalism in Czechia.
>>
>> You are demonstrating that you can guess the road class from other data.
>> I think it's cute, but does not match on-the-ground data in countries where
>> road classification is well-defined.
>>
>> Look, I've spent a lot of time on this and I have better things to do.
>> Fill in the info for your regions on the wiki and then we can see what we
>> can do. Until then, bear in mind that "harmonising" European roads will
>> likely get you banned. I don't want to sound like I'm threatening you, but
>> I've probably spent all the time I'm willing to spend on arguing with some
>> random person who wants to break our local road classification system
>> "because it will look nicer".
>>
>> On 24 February 2018 at 07:59, djakk djakk  wrote:
>>
>>> Yes, but this rendering does not change when a road crosses a border ^^
>>>
>>> djakk
>>>
>>>
>>> Le sam. 24 févr. 2018 à 05:43, JB  a écrit :
>>>
 There is something I don't get.
 Draw primary the same color as trunk and you have no more «
 discontinuity »?
 In France, some commercial map (the most sold, I think) use a different
 rendering for trunk and primary, because you drive faster on trunks. I
 like it, I think they like it, because they have been using this
 rendering for decades.
 JB.

 Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
 > As an exercise (and I'm curious about your thoughts on this), I found
 > the main routes between place=city within Czechia (didn't have time to
 > include cities in adjacent countries, bear that in mind).
 >
 > Here's the result [1] using the old colour scheme (motorway=blue,
 > trunk=green, primary=red; with a little mistake: secondary=yellow).
 > Top image uses the current classifications, and bottom image is the
 > result if city-city routes are classified as trunks. Looks very
 > similar to most other maps. Just by 

Re: [Talk-es] Maps, app libre en F-Droid basada en MAPS.ME

[Héctor Ochoa]

Maps.me ya era de código abierto, y tiene una licencia libre, pero contiene
algunas partes no libres, y de ahí este fork.
Repositorio de maps.me oficial: https://github.com/mapsme/omim

El 24 de febrero de 2018, 11:02, María Arias de Reyna 
escribió:

> Yo es la que uso siempre.
>
> El 24 feb. 2018 10:51, "Javier Sánchez Portero" 
> escribió:
>
>> Mola y mucho, por que parece que han publicado todo el código de maps.me
>> https://gitlab.com/axet/omim/tree/HEAD
>>
>> Gracias por el aviso
>>
>> El 22 de febrero de 2018, 16:40, Iván Hernández Cazorla <
>> ivanher...@gmail.com> escribió:
>>
>>> Buenas,
>>> Creo que el título lo dice todo. Me gustaría compartir con ustedes una
>>> aplicación que encontré hoy en F-Droid [0] y que fue publicada hace solo
>>> dos días. Se trata de Maps [1] y está basada en MAPS.ME [2], un
>>> servicio que se que muchos de ustedes también usan. Puede que les guste, ya
>>> que se trata de una versión más acorde a los principios de los proyectos en
>>> los que trabajamos, al menos desde mi punto de vista claro.
>>>
>>> Yo suelo utilizar OsmAnd, también en F-Droid [3]. Pero quise probar esta
>>> para y comprobar qué tal funciona. De momento me he descargado el mapa
>>> mundi general, necesario para la app, y el mapa de Canarias, y parece que
>>> funciona bastante bien.
>>>
>>> Lo dicho, se las dejo por si la quieren probar. Sobre todo para Miguel,
>>> que sé que, aunque creo que prefiere OsmAnd, seguro querrá probarla al ser
>>> una app FOSS [4].
>>>
>>> Saludos,
>>> Iván
>>>
>>> [0]: repositorio de aplicaciones libres y de código abierto para
>>> Android: https://f-droid.org/en/about/
>>> [1]: https://f-droid.org/packages/com.github.axet.maps/
>>> [2]: https://maps.me/
>>> [3]: https://f-droid.org/packages/net.osmand.plus/
>>> [4]: https://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3dig
>>> o_abierto
>>> --
>>> Iván Hernández Cazorla
>>> Miembro de Wikimedia España
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>


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

Re: [Talk-es] Maps, app libre en F-Droid basada en MAPS.ME

[María Arias de Reyna]

Yo es la que uso siempre.

El 24 feb. 2018 10:51, "Javier Sánchez Portero" 
escribió:

> Mola y mucho, por que parece que han publicado todo el código de maps.me
> https://gitlab.com/axet/omim/tree/HEAD
>
> Gracias por el aviso
>
> El 22 de febrero de 2018, 16:40, Iván Hernández Cazorla <
> ivanher...@gmail.com> escribió:
>
>> Buenas,
>> Creo que el título lo dice todo. Me gustaría compartir con ustedes una
>> aplicación que encontré hoy en F-Droid [0] y que fue publicada hace solo
>> dos días. Se trata de Maps [1] y está basada en MAPS.ME [2], un servicio
>> que se que muchos de ustedes también usan. Puede que les guste, ya que se
>> trata de una versión más acorde a los principios de los proyectos en los
>> que trabajamos, al menos desde mi punto de vista claro.
>>
>> Yo suelo utilizar OsmAnd, también en F-Droid [3]. Pero quise probar esta
>> para y comprobar qué tal funciona. De momento me he descargado el mapa
>> mundi general, necesario para la app, y el mapa de Canarias, y parece que
>> funciona bastante bien.
>>
>> Lo dicho, se las dejo por si la quieren probar. Sobre todo para Miguel,
>> que sé que, aunque creo que prefiere OsmAnd, seguro querrá probarla al ser
>> una app FOSS [4].
>>
>> Saludos,
>> Iván
>>
>> [0]: repositorio de aplicaciones libres y de código abierto para Android:
>> https://f-droid.org/en/about/
>> [1]: https://f-droid.org/packages/com.github.axet.maps/
>> [2]: https://maps.me/
>> [3]: https://f-droid.org/packages/net.osmand.plus/
>> [4]: https://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3dig
>> o_abierto
>> --
>> Iván Hernández Cazorla
>> Miembro de Wikimedia España
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-it] feedback da FOSS4G-IT 2018

[Alessandro Palmas]

  
  

  
Ciao
lista,
durante FOSS4G-IT abbiamo avuto modo di colloquiare con Enti
pubblici e Istituzioni varie che, anche se dal di fuori a volte non
si vede, utilizzano ampiamente OSM. Questi colloqui non sono stati
casuali ma frutto di settimane, a volte mesi, di contatti
precedenti.
Da questi interessanti colloqui sono arrivate diverse richieste,
alcune delle quali toccano direttamente i mappatori sul campo per la
mappatura di alcune caratteristiche.

Per farla breve le richieste hanno toccano le seguenti
caratteristiche:
- limiti di peso e sagoma sul grafo stradale (sia per i mezzi di
emergenza che per il traffico eccezionale)
- larghezza stimata delle principali strade sterrate (per gli
interventi antincendio boschivo)
- numero di corsie delle strade (per statistiche sui flussi di
traffico e incidenti, ma anche per dare maggior qualità ai
navigatori che usano OSM)
- la presenza di illuminazione nei parcheggi (specialmente vicini ai
luoghi di aggregazione serali e notturni)
- l'uso del suolo agricolo (la caratteristica meno semplice da
mappare tra tutte quelle in elenco)
- informazioni sull’accessibilità di POI e dei percorsi pedonali per
raggiungerli. Questi ultimi arrivano da diverse associazioni che
hanno a cuore il tema della fruibilità delle città da parte dei
propri cittadini ma anche per i turisti che arrivano da fuori.
Questo argomento dovrebbe essere oggetto di progetti che spero
partiranno nei prossimi mesi a Roma e Milano.

Come potete vedere, a parte la seconda sulle strade sterrate, sono
tutte proprietà che più o meno tutti inserirebbero una volta aver
raggiunto una decente mappatura di base nell’area che normalmente
coprono. E sono anche caratteristiche che non richiedono conoscenze
particolari nelle tecniche e nei tag da aggiungere.

E qui mi e vi chiedo: è proprio impensabile riuscire a fare delle
semplicissime campagna di sensibilizzazione verso la mappatura di
semplici elementi come questi? Diversi anni fa ci avevamo provato
con la mappatura del mese o un nome simile ma con scarsissimo
successo, tanto che dopo 4 mesi fu abbandonata.
Pensate al valore aggiunto che daremmo a OSM con queste semplici
informazioni.

Che ne dite?

Alessandro Ale_Zena_IT
  


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

Re: [Talk-es] Maps, app libre en F-Droid basada en MAPS.ME

[Javier Sánchez Portero]

Mola y mucho, por que parece que han publicado todo el código de maps.me
https://gitlab.com/axet/omim/tree/HEAD

Gracias por el aviso

El 22 de febrero de 2018, 16:40, Iván Hernández Cazorla <
ivanher...@gmail.com> escribió:

> Buenas,
> Creo que el título lo dice todo. Me gustaría compartir con ustedes una
> aplicación que encontré hoy en F-Droid [0] y que fue publicada hace solo
> dos días. Se trata de Maps [1] y está basada en MAPS.ME [2], un servicio
> que se que muchos de ustedes también usan. Puede que les guste, ya que se
> trata de una versión más acorde a los principios de los proyectos en los
> que trabajamos, al menos desde mi punto de vista claro.
>
> Yo suelo utilizar OsmAnd, también en F-Droid [3]. Pero quise probar esta
> para y comprobar qué tal funciona. De momento me he descargado el mapa
> mundi general, necesario para la app, y el mapa de Canarias, y parece que
> funciona bastante bien.
>
> Lo dicho, se las dejo por si la quieren probar. Sobre todo para Miguel,
> que sé que, aunque creo que prefiere OsmAnd, seguro querrá probarla al ser
> una app FOSS [4].
>
> Saludos,
> Iván
>
> [0]: repositorio de aplicaciones libres y de código abierto para Android:
> https://f-droid.org/en/about/
> [1]: https://f-droid.org/packages/com.github.axet.maps/
> [2]: https://maps.me/
> [3]: https://f-droid.org/packages/net.osmand.plus/
> [4]: https://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3digo_abierto
> --
> Iván Hernández Cazorla
> Miembro de Wikimedia España
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Matej, you don’t have to answer quickly, you can answer one time per week
if you prefer, the strong arguments will still weight well :)

djakk


Le sam. 24 févr. 2018 à 10:30, djakk djakk  a écrit :

> There is 2 « independant » things in the debate :
> 1) trunk definition - what is a trunk, a motorway-like road - based on
> physical characteristics- or a super-primary road - based on the importance
> ?
> 2) wordwilde trunk definition ? - should we have the same definition all
> over the world of what is highway= trunk ? (value that are
> country-dependant are not that common, aren’t they ?)
>
> djakk
>
>
> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský <
> lieskovsky.ma...@gmail.com> a écrit :
>
>> 1) If you want to look at a professional map of Czechia, I'd recommend
>> www.mapy.cz over google maps as that is the most used and far more
>> detailed map.
>> 2) I agree that the discontinuities are ugly, but they reflect the state
>> on the ground. That section around Sulec is a trunk instead of a primary
>> due to the fact that it is a section of future motorway built to motorway
>> standard. While your system heavily preferences "importance" of roads, our
>> local system reflects reality. Declaring the entire road from Pilsen to
>> České Budějovice as trunk due to its importance loses the information that
>> there is a section that was built as a motorway link to Písek. I can
>> already tell that the road is important because it links Pilsen and České
>> Budějovice (by looking at the map), but I also want to know that it was
>> built as a primary road and not as a trunk - that means that I'm going to
>> expect more single-level junctions and only two lanes for most of the way.
>>
>> I agree, our trunk roads are a little fuzzy on their definition, but
>> elevating random primary roads to trunk is a loss of data for us. Touching
>> anything else than reclassifying primary to trunk et vice versa will
>> certainly be considered as vandalism in Czechia.
>>
>> You are demonstrating that you can guess the road class from other data.
>> I think it's cute, but does not match on-the-ground data in countries where
>> road classification is well-defined.
>>
>> Look, I've spent a lot of time on this and I have better things to do.
>> Fill in the info for your regions on the wiki and then we can see what we
>> can do. Until then, bear in mind that "harmonising" European roads will
>> likely get you banned. I don't want to sound like I'm threatening you, but
>> I've probably spent all the time I'm willing to spend on arguing with some
>> random person who wants to break our local road classification system
>> "because it will look nicer".
>>
>> On 24 February 2018 at 07:59, djakk djakk  wrote:
>>
>>> Yes, but this rendering does not change when a road crosses a border ^^
>>>
>>> djakk
>>>
>>>
>>> Le sam. 24 févr. 2018 à 05:43, JB  a écrit :
>>>
 There is something I don't get.
 Draw primary the same color as trunk and you have no more «
 discontinuity »?
 In France, some commercial map (the most sold, I think) use a different
 rendering for trunk and primary, because you drive faster on trunks. I
 like it, I think they like it, because they have been using this
 rendering for decades.
 JB.

 Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
 > As an exercise (and I'm curious about your thoughts on this), I found
 > the main routes between place=city within Czechia (didn't have time to
 > include cities in adjacent countries, bear that in mind).
 >
 > Here's the result [1] using the old colour scheme (motorway=blue,
 > trunk=green, primary=red; with a little mistake: secondary=yellow).
 > Top image uses the current classifications, and bottom image is the
 > result if city-city routes are classified as trunks. Looks very
 > similar to most other maps. Just by looking at it, it's quite obvious
 > which is the main route between each pair of cities. As expected, the
 > method also found out the best ways through and around Praha when
 > going across it. This could also be slightly improved - for example,
 > with little extra time, it is easier to recommend going through route
 > 6 and then Karlovarská than through route 5 and Bucharova.
 >
 > I've checked the three small secondary segments using Street View.
 > Their physical structure is quite good. If still considered
 > undersirable, there are alternative main ways that increase the total
 > time of travel very slightly. Not all routers agreed on taking them
 > anyway.
 >
 > [1] https://i.imgur.com/qFGSveX.jpg
 >
 > ___
 > talk mailing list
 > talk@openstreetmap.org
 > https://lists.openstreetmap.org/listinfo/talk


 ___
 talk mailing list
 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

There is 2 « independant » things in the debate :
1) trunk definition - what is a trunk, a motorway-like road - based on
physical characteristics- or a super-primary road - based on the importance
?
2) wordwilde trunk definition ? - should we have the same definition all
over the world of what is highway= trunk ? (value that are
country-dependant are not that common, aren’t they ?)

djakk


Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský 
a écrit :

> 1) If you want to look at a professional map of Czechia, I'd recommend
> www.mapy.cz over google maps as that is the most used and far more
> detailed map.
> 2) I agree that the discontinuities are ugly, but they reflect the state
> on the ground. That section around Sulec is a trunk instead of a primary
> due to the fact that it is a section of future motorway built to motorway
> standard. While your system heavily preferences "importance" of roads, our
> local system reflects reality. Declaring the entire road from Pilsen to
> České Budějovice as trunk due to its importance loses the information that
> there is a section that was built as a motorway link to Písek. I can
> already tell that the road is important because it links Pilsen and České
> Budějovice (by looking at the map), but I also want to know that it was
> built as a primary road and not as a trunk - that means that I'm going to
> expect more single-level junctions and only two lanes for most of the way.
>
> I agree, our trunk roads are a little fuzzy on their definition, but
> elevating random primary roads to trunk is a loss of data for us. Touching
> anything else than reclassifying primary to trunk et vice versa will
> certainly be considered as vandalism in Czechia.
>
> You are demonstrating that you can guess the road class from other data. I
> think it's cute, but does not match on-the-ground data in countries where
> road classification is well-defined.
>
> Look, I've spent a lot of time on this and I have better things to do.
> Fill in the info for your regions on the wiki and then we can see what we
> can do. Until then, bear in mind that "harmonising" European roads will
> likely get you banned. I don't want to sound like I'm threatening you, but
> I've probably spent all the time I'm willing to spend on arguing with some
> random person who wants to break our local road classification system
> "because it will look nicer".
>
> On 24 February 2018 at 07:59, djakk djakk  wrote:
>
>> Yes, but this rendering does not change when a road crosses a border ^^
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 05:43, JB  a écrit :
>>
>>> There is something I don't get.
>>> Draw primary the same color as trunk and you have no more «
>>> discontinuity »?
>>> In France, some commercial map (the most sold, I think) use a different
>>> rendering for trunk and primary, because you drive faster on trunks. I
>>> like it, I think they like it, because they have been using this
>>> rendering for decades.
>>> JB.
>>>
>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
>>> > As an exercise (and I'm curious about your thoughts on this), I found
>>> > the main routes between place=city within Czechia (didn't have time to
>>> > include cities in adjacent countries, bear that in mind).
>>> >
>>> > Here's the result [1] using the old colour scheme (motorway=blue,
>>> > trunk=green, primary=red; with a little mistake: secondary=yellow).
>>> > Top image uses the current classifications, and bottom image is the
>>> > result if city-city routes are classified as trunks. Looks very
>>> > similar to most other maps. Just by looking at it, it's quite obvious
>>> > which is the main route between each pair of cities. As expected, the
>>> > method also found out the best ways through and around Praha when
>>> > going across it. This could also be slightly improved - for example,
>>> > with little extra time, it is easier to recommend going through route
>>> > 6 and then Karlovarská than through route 5 and Bucharova.
>>> >
>>> > I've checked the three small secondary segments using Street View.
>>> > Their physical structure is quite good. If still considered
>>> > undersirable, there are alternative main ways that increase the total
>>> > time of travel very slightly. Not all routers agreed on taking them
>>> > anyway.
>>> >
>>> > [1] https://i.imgur.com/qFGSveX.jpg
>>> >
>>> > ___
>>> > 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
>>
>>
>
___
talk mailing list
talk@openstreetmap.org

[Talk-it] Unione layer

[Gabriele Perrini]

Salve a tutti,
spero che qualcuno possa aiutarmi!!!
Premessa: sto inserendo sull'editor offline JOSM i percorsi di bike sharing
che verranno realizzati nel Comune di Palermo.
Tranquilli non intendo caricare online su OSM tali dati fin quando non
verranno effettivamente realizzati.
Allo stato attuale mi accontenterò di lavorare solamente offline.
Seguendo il progetto del Comune di Palermo (Piano della mobilità dolce) ho
creato su JOSM diversi layer ovvero:
1) Un layer contenente i percorsi
2) Un layer contenente i cicloposteggi
3) Un layer contenente la mappa di Palermo (da Slippy map)
Ok, fin qui tutto bene...adesso ho selezionato tutti i tre i layer -->
tasto destro --> unisci --> e salvato il tutto in un unico progetto!
Adesso, vista l'impossibilità di caricare ad oggi i miei dati online e
quindi di poter "sperimentare la tesi" solamente offline, decido di fare
delle simulazioni con l'applicazione sempre offline denominata
OpenTripPlanner (OTP).
Sono arrivato all'obiettivo finale della mia tesi quindi il mio ultimo
passaggio verrà basato sull'identificazione di 10 percorsi nei quali
verranno calcolati gli spostamenti a piedi, in bici, con tutti i mezzi di
trasporto ecc...!
Selezionando un punto di partenza e uno di arrivo e calcolando il tragitto
"in bici" succede che i percorsi, che avevo precedentemente costruito su
JOSM, compaiono a metà nel report finale.
Se ad esempio il mio percorso di chiama "A" e io calcolo in percorso lungo
A mi dice: Percorri la via NOME VIA e quindi non fa nessun cenno al
percorso A.
Ecco le Domande che mi/Vi pongo per constatare se magari ho commesso
qualche errore su JOSM oppure ho qualche dubbio in merito cioè:
1) Se magari ho unito in maniera errata i miei layer oppure se unendo i
layer ad una mappa, la mappa tende ad andare in primo piano rispetto alle
linee da me create??
2) Quando ho taggato i percorsi magari ho sbagliato ad inserire la Key e il
Value principale --> io ho inserito, ad esempio ipotizzando un percorso
denominato A, highway=residental e cycleway=lane cioè io ho identificato la
strada e la pista ciclabile al suo interno! Domanda visto: che su OTP i
dati sugli altri mezzi pubblici sono già presenti e io devo solamente
aggiungere il servizio di bike sharing dovevi mettere ad essere
direttamente highway=cycleway cioè inserire solamente dati relativi ai
percorsi ciclabili?
Spero qualcuno possa aiutarmi, sono agli sgoccioli della mia tesi e
sicuramente un piccolo problema non mi permette di analizzare tali dati
Grazie per l'attenzione
Gabriele
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Zones géographiques informelles

[Christian Quest]

Le 24 février 2018 à 01:30, Jérôme Amagat  a écrit
:

>
>
> Le 23 février 2018 à 22:13, marc marc  a écrit
> :
>
>> Le 23. 02. 18 à 14:55, Jérôme Amagat a écrit :
>> > comment ont fait pour différencier par exemple les Alpes et un de ses
>> > massifs?
>>
>> name=Les Alpes <> name=le nom du massif ? :)
>>
>
> Je parler bien sur de comment l'afficher sur un rendu ou comment s'en
> servir d'une façon ou d'une autre si ce n'est qu'un node. (c'est pareil
> avec le node name=Paris et name="un petit hameau" avec le nom on voit la
> différence mais ça suffit pas)
>


Un node seul pourrait être suffisant, ce n'est pas le name=* qui va
permettre au règles du rendu de décider de l'afficher ou pas, ce sont les
autres tags.
Pour Paris, ce sont des tags comme capital=* admin_level=*, mais aussi le
nombre de tags ou d'autres critères qui peuvent servir à prioriser.

Ceci dit, un polygone fournit quand même bien plus d'information (surface,
mais pourquoi pas orientation générale), et permet comme ça a été indiqué
de chercher des objets à l'intérieur ou à proximité de cette zone même si
ses contours sont flous.


Besoin de multipolygon ?

Ils sont nécessaires si les way de contour dépassent 2000 noeuds (limite
d'un way), mais avec autant de noeuds on est assez peu "flou" où si on a
des trous ou discontinuité...
Ils sont utiles (mais pas indispensables) si il y a une continuité
topologique entre zones floues contigues ou si ils s'appuient sur des way
existants (par exemple des frontières de limite de communes, mais on
devient du coup là encore très peu "flou").

Dans les autres cas, c'est compliquer inutilement la modélisation pour rien
(attention à la relationite).

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

[OSM-talk-fr] Usage d'OSM par les services de secours du pays-bas

[David Crochet]

Bonjour

petite vidéo avec OSM et surcouches : https://youtu.be/_jGGZq6_6hw?t=334

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Christian Quest]

Le 23 février 2018 à 22:35, marc marc  a écrit :

> Bonjour,
>
> Le 23. 02. 18 à 12:31, Christian Quest a écrit :
> > JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5
> > objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets).
>
> La limite du changeset a été baissé de 50k à 10k l'an passé
> https://wiki.openstreetmap.org/w/index.php?title=API_v0.
> 6=next=1431627
> $ wget -q -O - https://api.openstreetmap.org/api/capabilities
>  
> josm sait gérer les multiples changeset  mais il a aussi un mode
> qui n’envoie qu'un changeset, c'est peut-être cela qui s'est passé.
>
>
Oups, j'avais pas vu ça... ça montre bien à quel point c'est transparent ;)


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

1) If you want to look at a professional map of Czechia, I'd recommend
www.mapy.cz over google maps as that is the most used and far more detailed
map.
2) I agree that the discontinuities are ugly, but they reflect the state on
the ground. That section around Sulec is a trunk instead of a primary due
to the fact that it is a section of future motorway built to motorway
standard. While your system heavily preferences "importance" of roads, our
local system reflects reality. Declaring the entire road from Pilsen to
České Budějovice as trunk due to its importance loses the information that
there is a section that was built as a motorway link to Písek. I can
already tell that the road is important because it links Pilsen and České
Budějovice (by looking at the map), but I also want to know that it was
built as a primary road and not as a trunk - that means that I'm going to
expect more single-level junctions and only two lanes for most of the way.

I agree, our trunk roads are a little fuzzy on their definition, but
elevating random primary roads to trunk is a loss of data for us. Touching
anything else than reclassifying primary to trunk et vice versa will
certainly be considered as vandalism in Czechia.

You are demonstrating that you can guess the road class from other data. I
think it's cute, but does not match on-the-ground data in countries where
road classification is well-defined.

Look, I've spent a lot of time on this and I have better things to do. Fill
in the info for your regions on the wiki and then we can see what we can
do. Until then, bear in mind that "harmonising" European roads will likely
get you banned. I don't want to sound like I'm threatening you, but I've
probably spent all the time I'm willing to spend on arguing with some
random person who wants to break our local road classification system
"because it will look nicer".

On 24 February 2018 at 07:59, djakk djakk  wrote:

> Yes, but this rendering does not change when a road crosses a border ^^
>
> djakk
>
>
> Le sam. 24 févr. 2018 à 05:43, JB  a écrit :
>
>> There is something I don't get.
>> Draw primary the same color as trunk and you have no more «
>> discontinuity »?
>> In France, some commercial map (the most sold, I think) use a different
>> rendering for trunk and primary, because you drive faster on trunks. I
>> like it, I think they like it, because they have been using this
>> rendering for decades.
>> JB.
>>
>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
>> > As an exercise (and I'm curious about your thoughts on this), I found
>> > the main routes between place=city within Czechia (didn't have time to
>> > include cities in adjacent countries, bear that in mind).
>> >
>> > Here's the result [1] using the old colour scheme (motorway=blue,
>> > trunk=green, primary=red; with a little mistake: secondary=yellow).
>> > Top image uses the current classifications, and bottom image is the
>> > result if city-city routes are classified as trunks. Looks very
>> > similar to most other maps. Just by looking at it, it's quite obvious
>> > which is the main route between each pair of cities. As expected, the
>> > method also found out the best ways through and around Praha when
>> > going across it. This could also be slightly improved - for example,
>> > with little extra time, it is easier to recommend going through route
>> > 6 and then Karlovarská than through route 5 and Bucharova.
>> >
>> > I've checked the three small secondary segments using Street View.
>> > Their physical structure is quite good. If still considered
>> > undersirable, there are alternative main ways that increase the total
>> > time of travel very slightly. Not all routers agreed on taking them
>> > anyway.
>> >
>> > [1] https://i.imgur.com/qFGSveX.jpg
>> >
>> > ___
>> > 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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Alessandro]

Il 24/02/2018 09:40, Aury88 ha scritto:

Simone Saviolo wrote

Però si potrebbe introdurre un'accademia. Neanche tanto per insegnare come
si mappa, quanto piuttosto per porre una barriera all'ingresso. Va bene
che
la si voglia tenere bassa, ma non può essere nulla. Anche solo un tutorial
con verifica finale eliminerebbe il 99,9% dei mappatori svogliati e dei
vandali casuali (rimarrebbe lo 0,1% di batteri indistruttibili).

Ciao,

Simone


qualche tempo fa avevo proposto una cosa del genere all'atto della
registrazione.. sia per istruire un po' i nuovi arrivati sia per scremare
tutti quei bot che all'epoca intasavano il diari con pubblicità varie (per
lo più in cinese o russo...ogni giorno)

l'idea consisteva fondamentalmente nel far "rimappare" alcuni elementi
all'utente (traccia una strada o il bordo di un edificio, assegna il tag
name, ecc ecc) oppure semplicemente identificare alcuni elementi da un
ortofoto (trovami 5 alberi, due case, 3 incroci ecc) per poi confrontarli
con la mappatura già presente in OSM...se i dati inseriti all'atto
dell'iscrizione divergeva da quanto presente su OSM era un bot  se era
corretto era un umano (o un bot estremamente capace)...la cosa non era
piaciuta per varie difficoltà di implementazione, ma continuo a pensare che
non fosse dopotutto un idea così malvagia.



Ciao Aury,
questa procedura potrebbe eliminare i bot ma non avrebbe effetto nè su 
molti vandali (su qualcuno sì perchè si scoccerebbe) e aiuterebbe poco 
chi commette errori per inesperienza.
Sul lato implementazione poi ci sarebbe da capire come attuare la cosa, 
ma almeno discuterne è già un primo passo.
In realtà quello che tu indichi è nè più nè meno di quello che fa oggi 
il tutorial di iD. Forse ci vorrebbe un qualcosa di più dei 3' della 
durata del tutorial. La cosa positiva è che ci potrebbe prendere il 
sistema del tutorial e ampliarlo, senza dover progettare il tutto da zero.


Alessandro Ale_Zena_IT

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Aury88]

Simone Saviolo wrote
> Però si potrebbe introdurre un'accademia. Neanche tanto per insegnare come
> si mappa, quanto piuttosto per porre una barriera all'ingresso. Va bene
> che
> la si voglia tenere bassa, ma non può essere nulla. Anche solo un tutorial
> con verifica finale eliminerebbe il 99,9% dei mappatori svogliati e dei
> vandali casuali (rimarrebbe lo 0,1% di batteri indistruttibili).
> 
> Ciao,
> 
> Simone

qualche tempo fa avevo proposto una cosa del genere all'atto della
registrazione.. sia per istruire un po' i nuovi arrivati sia per scremare
tutti quei bot che all'epoca intasavano il diari con pubblicità varie (per
lo più in cinese o russo...ogni giorno)

l'idea consisteva fondamentalmente nel far "rimappare" alcuni elementi
all'utente (traccia una strada o il bordo di un edificio, assegna il tag
name, ecc ecc) oppure semplicemente identificare alcuni elementi da un
ortofoto (trovami 5 alberi, due case, 3 incroci ecc) per poi confrontarli
con la mappatura già presente in OSM...se i dati inseriti all'atto
dell'iscrizione divergeva da quanto presente su OSM era un bot  se era
corretto era un umano (o un bot estremamente capace)...la cosa non era
piaciuta per varie difficoltà di implementazione, ma continuo a pensare che
non fosse dopotutto un idea così malvagia.





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

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

Re: [OSM-talk] Is this legal to what philly.com is doing?

[Martin Koppenhoefer]

sent from a phone

> On 23. Feb 2018, at 15:40, Paul Norman  wrote:
> 
> Yes. They need to either be attributing OSM, or if the image is taken from an 
> osm.org render, attributing OSM and licensing it CC BY-SA.



indeed they can sell the images, but they have to attribute and mention the 
license (and can’t claim copyright over osm cartography), which they apparently 
don’t do correctly at the moment (on the linked page there’s their copyright 
but not osm’s).

Cheers,
Martin 


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

Re: [Talk-es] Carretera sin línea central

[Javier Sánchez Portero]

Pues tienes razón. Además está indicado explícitamente lo opuesto

https://wiki.openstreetmap.org/wiki/Key:lane

"key to tag how many **marked** traffic lanes there are"

O sea, que si no tiene la raya hay que poner lanes=1.

El 23 de febrero de 2018, 21:09, Jorge Sanz Sanfructuoso 
escribió:

> Dónde está indicado eso de que por tener un carril sea oneway a la fuerza?
> No tiene porqué.
>
>
> El vie., 23 feb. 2018 18:10, Javier Sánchez Portero 
> escribió:
>
>> Si pones lanes=1 implica oneway=yes. Es una carretera de doble sentido.
>>
>> El 23 de febrero de 2018, 17:00, Jorge Sanz Sanfructuoso <
>> sanc...@gmail.com> escribió:
>>
>>> Yo esas las pongo como lanes=1, no hace falta poner oneway=no . Ya
>>> indica lo que es con eso.
>>>
>>> El vie., 23 feb. 2018 a las 17:55, Javier Sánchez Portero (<
>>> javiers...@gmail.com>) escribió:
>>>
 Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se
 cual sería el término adecuado en inglés.

 El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega <
 i...@sanchezortega.es> escribió:

> On 2018-02-23 14:51, Javier Sánchez Portero wrote:
>
>> Hola
>>
>> Hay sitios rurales en los que las carreteras no tienen pintada línea
>> central. Pueden ser unclassified, tertiary o incluso secondary. Por
>> supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
>> etiqueta para indicarlo? El método más heavy sería lanes=1
>> oneway=no, pero me resulta.
>>
>
> Creo que se trata de carreteras de dos carriles (uno por sentido), sin
> separación por marcas viales.
>
> Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:
>
> En las calzadas con doble sentido de circulación y dos carriles,
>> SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.
>>
>
> Es decir, es perfectamente posible una carretera con calzada de doble
> sentido y un carril para cada sentido de la circulación, aun cuando no 
> haya
> señales horizontales (línea pintada) que los separen.
>
>
> [1] http://www.dgt.es/es/seguridad-vial/normativa-y-
> legislacion/reglamento-trafico/circulacion-general/normas-basicas/
>
> --
> Iván Sánchez Ortega 
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>

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

>>> --
>>> Jorge Sanz Sanfructuoso - Sanchi
>>> Blog http://jorgesanz.es/
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://jorgesanz.es/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es