date:20141219

2014-12-18 21:41 GMT+01:00 Andy Street a...@street.me.uk:

  They try to push that tag everywhere even when the tag without the
  prefix is used 10x more.

 This is the ad populum fallacy. Any attempt to improve a tagging scheme
 will always start out being numerically weaker regardless of the merit
 of the proposal.




yes, but if you look in this case on the wiki history, it was created
almost 6 years ago (Jan 2009) by copying info from another page (i.e. this
is likely older then 6 years). In all this time this alternative way of
tagging didn't find enough support to even come closer to the un-prefixed
tagging alternative. IMHO we shouldn't wait any longer and declare the
alternative way for deprecated.
http://wiki.openstreetmap.org/w/index.php?title=Key:contactaction=history

There are also strange suggestions like contact:webcam (how would you
contact someone via his public webcam?) and some documented keys are not
even used 5 times (one has no occurence at all). These are at best
proposals but shouldn't be in a Key:-Definition page.

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

[OSM-talk] Back on OSM

2014-12-19 Thread Peter

Hallo iedereen, 

Eindelijk nog eens vrije tijd en natuurlijk kwam OSM weer op de proppen.
Dacht beginnen te mappen voor mijn dorp (Peutie) maar zie dat er de laatste 
tijd al veel aangepast werd. Nu stel ik vast dat er verschillende manieren 
worden gebruikt in het aanmaken van huizen, plaatsen van nummers enz
Wat is nu de juiste manier om huizen en hun nummer op de kaart te zetten want 
wat betreft Peutie zie ik uiteenlopende mogelijkheden.

If someone needs this mail in English feel free to let me know.

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

Re: [OSM-talk] Back on OSM

2014-12-19 Thread Michael Reichert

Hi,

Am 2014-12-19 um 13:33 schrieb Peter:
 Eindelijk nog eens vrije tijd en natuurlijk kwam OSM weer op de proppen.
 Dacht beginnen te mappen voor mijn dorp (Peutie) maar zie dat er de laatste 
 tijd al veel aangepast werd. Nu stel ik vast dat er verschillende manieren 
 worden gebruikt in het aanmaken van huizen, plaatsen van nummers enz
 Wat is nu de juiste manier om huizen en hun nummer op de kaart te zetten want 
 wat betreft Peutie zie ik uiteenlopende mogelijkheden.
 
 If someone needs this mail in English feel free to let me know.

Ja, i hätt gern dei Mail uf Deitsch oder Englisch. I kann koi
Holländisch. [3]

I only understand English and German. This is an mailing list in English
language. For Dutch mails please use either talk-nl [1] or talk-be [2].

Best regards/Viele Grüße

Michael



[1] https://lists.openstreetmap.org/listinfo/talk-nl
[2] https://lists.openstreetmap.org/listinfo/talk-be
[3] This is Swabian.

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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

Re: [OSM-talk] Back on OSM

2014-12-19 Thread Matthijs Melissen

As this is a question specifically relating to the situation in the
Netherlands, best to ask your question on the Dutch forum:
http://forum.openstreetmap.org/viewforum.php?id=12

-- Matthijs

2014-12-19 12:33 GMT+00:00 Peter pe...@out4walkabout.be:
 Hallo iedereen,

 Eindelijk nog eens vrije tijd en natuurlijk kwam OSM weer op de proppen.
 Dacht beginnen te mappen voor mijn dorp (Peutie) maar zie dat er de laatste 
 tijd al veel aangepast werd. Nu stel ik vast dat er verschillende manieren 
 worden gebruikt in het aanmaken van huizen, plaatsen van nummers enz
 Wat is nu de juiste manier om huizen en hun nummer op de kaart te zetten want 
 wat betreft Peutie zie ik uiteenlopende mogelijkheden.

 If someone needs this mail in English feel free to let me know.

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

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

Re: [OSM-talk] Wiki - contact: Tag Map Features

2014-12-19 Thread Andreas Goss


There are also strange suggestions like contact:webcam (how would you
contact someone via his public webcam?) and some documented keys are not
even used 5 times (one has no occurence at all). These are at best
proposals but shouldn't be in a Key:-Definition page.


And with contact:facebook, contact:twitter etc. you have a similar 
issue, because not every company uses it that way. Some might just have 
a page and post stuff, but never reply or read anything.


__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [OSM-talk] Back on OSM

2014-12-19 Thread Marc Gemis

Peter, I think you have this accidentally to the talk mailing list instead
of the Belgian list.
Perhaps you can read
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data
.

In general the house numbers are mostly placed on the buildings in Belgium.
In some cases you can use address nodes in case it is difficult to
determine the walls between the houses. An other exception in when there
are different house numbers for flats on different floors.

Anyhow, feel free to continue the discussion on the Belgian mailing list.

regards

p.s. good to see you back

2014-12-19 13:33 GMT+01:00 Peter pe...@out4walkabout.be:

 Hallo iedereen,

 Eindelijk nog eens vrije tijd en natuurlijk kwam OSM weer op de proppen.
 Dacht beginnen te mappen voor mijn dorp (Peutie) maar zie dat er de
 laatste tijd al veel aangepast werd. Nu stel ik vast dat er verschillende
 manieren worden gebruikt in het aanmaken van huizen, plaatsen van nummers
 enz
 Wat is nu de juiste manier om huizen en hun nummer op de kaart te zetten
 want wat betreft Peutie zie ik uiteenlopende mogelijkheden.

 If someone needs this mail in English feel free to let me know.

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

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

Re: [OSM-talk] Wiki - contact: Tag Map Features

2014-12-19 Thread Dave F.


On 18/12/2014 21:27, Andreas Goss wrote:


Well, it's kinda what contact does. 
http://wiki.openstreetmap.org/wiki/Key:contact




I can't believe this has reared its ugly head again. How little/much 
it's used is really irrelevant. It's usefulness is what counts  
prefixing a tag adds no value.


From memory the original claim was all 'contacts' could be filtered out 
in one go, but it was pointed out that post filtering would still need 
to be performed, and I'm no programming expert, but I was led to believe 
parsing a string like 'contact:email' is slow.


The wiki page doesn't actually say why it's needed.

Dave F.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


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

Re: [OSM-talk] Wiki - contact: Tag Map Features

2014-12-19 Thread Mike N


On 12/19/2014 3:47 PM, Dave F. wrote:

 From memory the original claim was all 'contacts' could be filtered out
in one go, but it was pointed out that post filtering would still need
to be performed, and I'm no programming expert, but I was led to believe
parsing a string like 'contact:email' is slow.


 In one go, there's this: 
http://taginfo.openstreetmap.org/search?q=contact .   As a programmer, I 
would tend to be in the contact: camp.   As an OSM contributor, I have 
since long sided with the non-contact: camp since the data consumers 
have been very slow on the uptake of the contact: form  - if anyone is 
even using it at all yet.



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

Re: [OSM-talk] Wiki - contact: Tag Map Features

2014-12-19 Thread Andreas Goss


In one go, there's this: http://taginfo.openstreetmap.org/search?q=contact


I still don't see when that is that usefull. I mean yeah it's nice to 
see which tags people use, but that could just be documented in the 
Wiki. When editing POIs then when a POI has contact information that 
usually makes up the majority of the tags anyway so contact: sorting 
helps little here (just look at the average store or restaurant). I 
actually find it easier to just look at the first letter of a tag to 
find it than to look at the letter after contact: Not to mention that 
it's much nicer for autocomplete.


I kida doubt someone will make an app and then just filter for 
contact:* Would you really want to list fax these days? Or 10x social 
media websites and not filter for the 2-3 common ones? Don't you want to 
format the address nicely? At that point it seems to be like you already 
have to look at each individual key anyway.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

[Talk-br] Lançamento do Mapazonia

2014-12-19 Thread Vitor George

Hoje foi lançado do site do Mapazônia:

www.mapazonia.org

Como podem ver, é necessário fazer a tradução ao português. Aqui está o
código:

https://github.com/osm-ar/mapazonia

Em breve vamos passar os links com as tarefas de mapeamento.

Abraço,
Vitor
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lançamento do Mapazonia

2014-12-19 Thread João Fernando

Publiquei uma notícia no site da Revista Espírito Livre para ajudar na
visibilidade do projeto e captação de possíveis colaboradores.

http://www.revista.espiritolivre.org/conheca-o-mapazonia-um-projeto-aberto-para-mapear-colaborativamente-a-amazonia-no-openstreetmap

att,

Em 19 de dezembro de 2014 15:34, Vitor George vitor.geo...@gmail.com
escreveu:

 Hoje foi lançado do site do Mapazônia:

 www.mapazonia.org

 Como podem ver, é necessário fazer a tradução ao português. Aqui está o
 código:

 https://github.com/osm-ar/mapazonia

 Em breve vamos passar os links com as tarefas de mapeamento.

 Abraço,
 Vitor

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




-- 

   _
  °v°  João Fernando Costa Júnior
 /(_)\ Comunidade LibreOffice do ES / Iniciativa Espírito Livre /
Equipe Bestlinux
  ^ ^  GNU/Linux User #422133   |   Ubuntu User #16167
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lançamento do Mapazonia

2014-12-19 Thread Vitor George

Obrigado!

Em Fri Dec 19 2014 at 4:33:24 PM, João Fernando 
joaoferna...@espiritolivre.org escreveu:

 Publiquei uma notícia no site da Revista Espírito Livre para ajudar na
 visibilidade do projeto e captação de possíveis colaboradores.


 http://www.revista.espiritolivre.org/conheca-o-mapazonia-um-projeto-aberto-para-mapear-colaborativamente-a-amazonia-no-openstreetmap

 att,

 Em 19 de dezembro de 2014 15:34, Vitor George vitor.geo...@gmail.com
 escreveu:

 Hoje foi lançado do site do Mapazônia:

 www.mapazonia.org

 Como podem ver, é necessário fazer a tradução ao português. Aqui está o
 código:

 https://github.com/osm-ar/mapazonia

 Em breve vamos passar os links com as tarefas de mapeamento.

 Abraço,
 Vitor

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




 --

_
   °v°  João Fernando Costa Júnior
  /(_)\ Comunidade LibreOffice do ES / Iniciativa Espírito Livre / Equipe 
 Bestlinux
   ^ ^  GNU/Linux User #422133   |   Ubuntu User #16167

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

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

[Talk-de] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

2014-12-19 Thread Martin Vonwald

Hi!

Da die Nutzung von maxspeed:variable kontinuierlich ansteigt, möchte ich
euch nochmals auf das entsprechende Proposal hinweisen:
https://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed

Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
überlegen, da es nicht nur die Information liefert, dass das
Geschwindigkeitslimit variabel ist, sondern zusätzlich:
* das höchste mögliche(!) Geschwindigkeitslimit
* den Grund(!) für das variable Limit

Ich halte beides für potentiell wertvolle Information für Datenkonsumenten.

Beispiel: Auf Autobahnen in Österreich gilt üblicherweise ein
Geschwindigkeitslimit von 130 km/h. Autobahnen, welche größere Städte
durchqueren, verfügen jedoch häufig über ein variables Limit und recht
häufig ist das maximale Limit 80km/h. 130km/h oder 80 km/h ist ein
ziemlicher Unterschied. Wenn wir nur die Information liefern, dass das
Limit variabel ist, welches Limit soll ein Datenkonsument annehmen?
Vielleicht ist es schneller die Stadt zu umfahren, da dort normalerweise
130 km/h gilt?


Ich möchte vorschlagen die Empfehlung zu maxspeed=signals aus dem Wiki zu
entfernen und stattdessen auf maxspeed:variable=Grund + maxspeed=maximal
mögliches Limit zu verweisen.

Beste Grüße,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Berliner OSM-Hackweekend 17/18 Januar 2015

2014-12-19 Thread Lars Lingner

Hallo,

in circa 4 Wochen, genau am 17./18. Oktober wird ein
OSM-Hackweekend in Berlin stattfinden. Alle Informationen findet ihr
wieder im Wiki [1]

Das Wichtigste:

Wann:  17./18. Januar 2015 jeweils ab 10:00 Uhr
Wo: Büro 2.0, Weigandufer 45, 12059 Berlin
ÖPNV: S-Sonnenallee, Karte siehe Wiki


Habt alle ein paar schöne Feiertage, erholt Euch, geht zum 31c3 [2] und
kommt gut im neuen Jahr an.

vorweihnachtliche Grüße aus Berlin

Lars


[1] http://wiki.osm.org/wiki/Berlin_Hack_Weekend_Januar_2015
[2] http://wiki.osm.org/wiki/Chaos_Communication_Congress/31C3

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

Re: [Talk-de] Berliner OSM-Hackweekend 17/18 Januar 2015

2014-12-19 Thread Lars Lingner

Hallo,

über Weihnachten übe ich noch mal copy+paste.

statt
On 19.12.2014 09:49, Lars Lingner wrote:
 in circa 4 Wochen, genau am 17./18. Oktober wird ein

muss es heißen
in circa 4 Wochen, genau am 17./18. Januar wird ein

(der Rest stimmt).

 OSM-Hackweekend in Berlin stattfinden. Alle Informationen findet ihr
 wieder im Wiki [1]
 
 Das Wichtigste:
 
 Wann:  17./18. Januar 2015 jeweils ab 10:00 Uhr
 Wo: Büro 2.0, Weigandufer 45, 12059 Berlin
 ÖPNV: S-Sonnenallee, Karte siehe Wiki
 
 
 Habt alle ein paar schöne Feiertage, erholt Euch, geht zum 31c3 [2] und
 kommt gut im neuen Jahr an.
 
 vorweihnachtliche Grüße aus Berlin
 
 Lars
 
 
 [1] http://wiki.osm.org/wiki/Berlin_Hack_Weekend_Januar_2015
 [2] http://wiki.osm.org/wiki/Chaos_Communication_Congress/31C3
 


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

Re: [Talk-de] [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 12/19/2014 09:31 AM, Martin Vonwald wrote:
 Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
 überlegen, da es nicht nur die Information liefert, dass das
 Geschwindigkeitslimit variabel ist, sondern zusätzlich:
 * das höchste mögliche(!) Geschwindigkeitslimit
 * den Grund(!) für das variable Limit

Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL.
Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit
die angezeigt werden kann, kann ich mir als normaler Mapper, der selten
Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen
sollen. Werden da dann Verordnungstexte in OSM eingepflegt oder wie kann
ich als Gelegenheitsmapper auf einer Autobahn feststellen, was denn hier
die richtige Geschwindigkeit ist? Ich kann mich nämlich nicht dran
erinnern in letzter Zeit noch irgendwo Stahlschilder neben Signalanlagen
gesehen zu haben.

Ich versteh den Grund warum die Daten drin sein sollen, aber für mich
schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort
nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas
Bauchweh.

Norbert

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

Re: [Talk-de] [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

2014-12-19 Thread Andreas Neumann

On 19.12.2014 12:03, Norbert Wenzel wrote:
 On 12/19/2014 09:31 AM, Martin Vonwald wrote:
 Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
 überlegen, da es nicht nur die Information liefert, dass das
 Geschwindigkeitslimit variabel ist, sondern zusätzlich:
 * das höchste mögliche(!) Geschwindigkeitslimit
 * den Grund(!) für das variable Limit
 
 Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL.
 Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit
 die angezeigt werden kann, kann ich mir als normaler Mapper, der selten
 Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen
 sollen. Werden da dann Verordnungstexte in OSM eingepflegt oder wie kann
 ich als Gelegenheitsmapper auf einer Autobahn feststellen, was denn hier
 die richtige Geschwindigkeit ist? Ich kann mich nämlich nicht dran
 erinnern in letzter Zeit noch irgendwo Stahlschilder neben Signalanlagen
 gesehen zu haben.
 
 Ich versteh den Grund warum die Daten drin sein sollen, aber für mich
 schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort
 nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas
 Bauchweh.
 
 Norbert

Ich mappe immer maxspeed=Maximale Geschwindigkeit,
source:maxspeed=signal, bzw. nutze seit kurzer Zeit auch das
angesprochene maxspeed:variable=yes

Auf deutschen Autobahnen gibt es ein einfaches Beispiel für die oben
genannte Situation: Tunnel. Sie sind meist nur durch Signalanlagen auf
80 gedrosselt, können aber in besonderen Fällen noch weiter gedrosselt
werden. Auch einige stark frequentierte Autobahnen, sind je nach
Auslastung bei 120km/h oder runtergedrosselt.

Für Gelegenheitsmapper ist es immer schwierig alles zu erfassen. Egal in
welchen Bereich wir gelegentlich hineinschauen. Die maximal zulässige
Geschwindigkeit sollte von Ortskundigen erfasst werden, und man sollte
diesen Daten vertrauen. Ist man sich nicht sicher, kann man immer noch
auf Notes zurückgreifen und den Zweifel der lokalen Community damit
mitteilen.

Was die temporäre Drosselung betrifft:
Wir mappen nur, was wir sehen und was eine gewisse Zeit bestand hat.
Diese Regeln entstammt aus einer Zeit, wo vermehrt Baustellen
eingetragen wurde, oder User versuchten die fahrbare Geschwindigkeit
in bestimmten Gebieten zu attributieren.

@Norbert:
Wer als Nutzer ein Traffic-basiertes Routing wünscht, greift selten auf
statische Daten, wie OSM zurück, sondern nutzt heutzutage
Community-basierte Router, wie Waze.

Frohe Feiertage,
Andreas


-- 
Andreas Neumann
http://Map4Jena.de
http://Stadtplan-Ilmenau.de



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

Re: [Talk-de] [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 12/19/2014 04:47 PM, Andreas Neumann wrote:
 On 19.12.2014 12:03, Norbert Wenzel wrote:
 On 12/19/2014 09:31 AM, Martin Vonwald wrote:
 Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
 überlegen, da es nicht nur die Information liefert, dass das
 Geschwindigkeitslimit variabel ist, sondern zusätzlich:
 * das höchste mögliche(!) Geschwindigkeitslimit
 * den Grund(!) für das variable Limit

 Ich versteh den Grund warum die Daten drin sein sollen, aber für mich
 schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort
 nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas
 Bauchweh.
 
 Ich mappe immer maxspeed=Maximale Geschwindigkeit,
 source:maxspeed=signal, bzw. nutze seit kurzer Zeit auch das
 angesprochene maxspeed:variable=yes

Ich akzeptier dass es genug Leute gibt die das mappen können auch wenn
es keine einfachen Quellen dafür gibt, die ein Mapper so schnell mal vor
Ort kontrollieren kann (zumindest nicht bei einem einzelnen Besuch). Ich
versteh nur noch immer nicht warum maxspeed= auf eine maximal erlaubte
Geschwindigkeit gesetzt wird. Das macht Sinn wenn wir davon ausgehen,
dass diese Drosselung nur selten aktiv ist.

Die in AT beliebten IGL Zonen (Immissionsschutzgesetz Luft) führen
allerdings dazu, dass zwar theoretisch 130 erlaubt ist, praktisch aber
nur 100 oder gar 80. Und zwar an deutlich mehr Tagen, als dort die
maximal erlaubten 130 gefahren werden dürfen.

Daher würd ich dafür plädieren, dass - wenn wir schon Daten erfassen,
die nur ortskundige Mapper aufgrund der wiederholten Beobachtung
schließen können (die Begrenzung hier zeigt nie mehr als x an) - wir
gleich die Geschwindigkeit erfassen die meistens gilt. Denn bei den von
mir genannten Beispielen bringt die Erfassung der Maximalgeschwindigkeit
genau keinen Mehrwert, wenn sie ohnehin meistens nicht zutrifft.

Ich halte das erfassen von maxspeed= bei gleichzeitiger Signalanlage
hier also im Allgemeinen für ein Vortäuschen einer Objektivität, die
nicht vorhanden ist. Und wenn ohnehin nur empirisch erfasste Werte
eingetragen werden, dann sollten wir die als solche kennzeichnen.

Das ist bei den von dir beschriebenen Tunneln dann der Wert den du
derzeit als maxspeed=* einträgst und bei den von mir beschriebenen IGL
Zonen halt dann die Beschränkung, weil die einfach öfter aktiv ist nicht.

 @Norbert:
 Wer als Nutzer ein Traffic-basiertes Routing wünscht, greift selten auf
 statische Daten, wie OSM zurück, sondern nutzt heutzutage
 Community-basierte Router, wie Waze.

Ich versteh nicht ganz was du mir damit sagen willst, hab aber den
Eindruck es ist für die Diskussion hier nicht wirklich wichtig.
Korrigier mich bitte falls ich das falsch seh, ansonsten können wir das
gern direkt per Mail klären, auf was sich die Antwort bezogen hat.

Norbert


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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

2014-12-19 Thread Hubert

Hallo,
ich habe einmal auf meiner Wiki Seite 
(https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein 
paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf 
der entsprechenden Diskussionsseite.

Außerdem:
Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de:
 Was dann aber noch fies bleibt, sind solche Wege die erst
 straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg).
 
 https://www.openstreetmap.org/way/202894636

Ja, solche Dinge sind wirklich schwierig zu entscheiden. Das muss der Mapper 
Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger 
geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht 
vorrausgesetzt.

 Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu
 vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde.

Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Im 
Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort 
aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt.

Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.

Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. 
Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar 
ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht 
wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu 
verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem 
Schema so ergibt, dann ist es (auf einmal) Ok.

Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer 
dieterdre...@gmail.com:
  da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.
 
 
 
 jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit
 eindeutig. separate_way hat das Problem, dass man erstens auch nicht
 genau weiss, welcher way, und zweitens bezieht man sich mit einem tag
 auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht
 schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg
 verändert muss halt auch noch die Straße anschauen (und auch wenn das
 im Prinzip schon genau das Problem ist, so kann man es für Straßen
 vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat
 (tags die sich auf andere in der Nähe liegende, nicht genau
 spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das
 Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist
 ein bisschen so ähnlich wie forward-Angaben auf einem Node.

Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* 
und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat 
eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst 
nachsehen ob die (street-)Relation zu der die Straße gehört und dann ob in der 
Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für 
mich kompliziert bis unmöglich.

Gruß
Hubert



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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

2014-12-19 Thread 715371

Am 19.12.2014 um 23:58 schrieb Hubert:
 Hallo,
 ich habe einmal auf meiner Wiki Seite 
 (https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein 
 paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf 
 der entsprechenden Diskussionsseite.
 
 Außerdem:
 Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de:
 Was dann aber noch fies bleibt, sind solche Wege die erst
 straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg).

 https://www.openstreetmap.org/way/202894636
 
 Ja, solche Dinge sind wirklich schwierig zu entscheiden. 


 Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von 
 der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, 
 Benutzungspflicht vorrausgesetzt.

Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn
man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere
Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt).

 
 Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu
 vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde.
 
 Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. 

Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das
doppelte Erfassen.

 Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg 
 dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt.

Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde,
dann würde ich den anschließenden Radweg nicht separat erfassen, weil es
dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen.

 
 Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly 
 lowfligh...@googlemail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.
 
 Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. 
 Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar 
 ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das 
 gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) 
 zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem 
 Schema so ergibt, dann ist es (auf einmal) Ok.

Ich halte beides für nicht so gelungen. cycleway=* ist für mich ein Key
mit dem man die Fahrradinfrastruktur an der Straße erfasst und würde es
so verstehen, dass es zwei Radwege dort gibt, wenn es an der Straße
einen cycleway=* gibt und daneben noch einen
highway=path/cycleway/(footway).

Daher sollte man IMHO für so etwas etwas anderes verwenden.

Was in dem Kontext halt auch ungünstig ist: Die Bedeutung von footway=*
ist nicht analog zu cycleway=*. cycleway eine weitere Bedeutung zu
geben, macht es nicht einfacher.

 Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer 
 dieterdre...@gmail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.



 jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit
 eindeutig. separate_way hat das Problem, dass man erstens auch nicht
 genau weiss, welcher way, und zweitens bezieht man sich mit einem tag
 auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht
 schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg
 verändert muss halt auch noch die Straße anschauen (und auch wenn das
 im Prinzip schon genau das Problem ist, so kann man es für Straßen
 vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat
 (tags die sich auf andere in der Nähe liegende, nicht genau
 spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das
 Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist
 ein bisschen so ähnlich wie forward-Angaben auf einem Node.
 
 Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B 
 sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch 
 einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter 
 müsste erst nachsehen ob die (street-)Relation
zu der die Straße gehört und dann ob in der Relation auch noch ein
Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert
bis unmöglich.

Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane
oder sidewalk=right an dieser Stelle nun gerendert wird.

Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht
ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B.
separate_cycletrack=left/right/both
und analog das für footway
separate_sidewalk=left/right/both

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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

2014-12-19 Thread 715371



Am 09.12.2014 um 13:17 schrieb Hubert:
 Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt 
 sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit 
 highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch 
 sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt 
 logisch wäre.

Mir fehlt hier noch die Diskussion weshalb man nun etwas separat
erfassen sollte bzw. nicht.

Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie
erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu
erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine
abgesenkt sind. Oder das zumindest so vorkommt, so dass man die
straßenbegleitenden Wege ohne Komplikationen befahren kann.

Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man
(in D-Land) eher als default annehmen sollte, dass alles
Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung
oder Einmündung alles machen können. Wenn das nicht der Fall sein
sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine
Relation einführen, die der restriction-Relation ähnelt.

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

Re: [osm-ve] Venezuelan address data

2014-12-19 Thread Wladimir Szczerban

Hi Tom,

Unfortunately the issue of data in Venezuela is a problem in many cases the
government has no data or if any are outdated, usually do not answer
queries and
requests. In rare cases with updated data do not share or sell them at high
prices.

Regarding directions there is no numbering as in other countries.
In Venezuela the buildings and houses have names and addresses are given for
reference in some cases the reference is the intersection or other indications
such cases The white building opposite the supermarket.

Here you can see an example of addresses of the offices of a bank

http://www.bancomercantil.com/mercprod/site/tools/ubicacion/capital_lista.html

There is a collaborative project similar to OSM called Venrut
http://www.gpsyv.net/ but unfortunately license is not compatible with OSM
in Venezuela. I tried to promote collaboration between Venrut and OSM but have
not been successful.

Venrut data have very good coverage of the territory although they are
intended primarily for use in GPS (Garmin)

Saludos,

Wladimir

Pd: regards Eric from Wladimir geoinquiets of Barcelona (Spain)



2014-12-15 17:17 GMT+01:00 Tom Lee t...@mapbox.com:

 First: apologies for my use of English. I'm afraid it would be even more
 annoying if I tried to speak Spanish.

 Second: I wonder if anyone in the Venezuelan OSM community knows about
 address point data. I am seeking a source for this information so that it
 can be contributed to the OpenAddresses.io project. I have not had much
 luck finding contacts at the Instituto Geográfico de Venezuela Simón
 Bolívar or the Instituto Nacional de Estadística, which seem most likely to
 have cadastral or other data that would meet my needs.

 Is anyone aware of who maintains this data and under what terms it is
 available? I would be grateful for any suggestions or information you can
 provide.

 Tom

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



-- 
Saludos,

Bolo
www.geoinquiets.cat
___
Talk-ve mailing list
Talk-ve@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ve

Re: [Talk-in] SoI / DST complain against Google.

2014-12-19 Thread Ravi Kumar

This is a tricky issue, as OSM is used on both sides of a boarder and so, 
cannot be easily settled.
http://www.un.org/Depts/Cartographic/map/profile/Souteast-Asia.pdf
see this and this also shows various types of lines at our boarder.
They display this apology too
The boundaries and names shown and the designations used
on this map do not imply official endorsement or acceptance
by the United Nations.
Dotted line represents approximately the Line of Control
in Jammu and Kashmir agreed upon by India and Pakistan.
The final status of Jammu and Kashmir has not yet been
agreed upon by the parties

Let us request OSM to steer clear of this and leave the boarder alone.. or show 
with a similar apology.

On Thu, 12/18/14, Aditya Nag aditya.nag.2...@gmail.com wrote:

 Subject: Re: [Talk-in] SoI / DST complain against Google.
 To: OpenStreetMap in India talk-in@openstreetmap.org
 Date: Thursday, December 18, 2014, 6:59 PM
 
 I feel that this problem
 cannot be solved just by having a separate
 server for OSM India:
 
 (A) We would most probably be using
 OpenStreetMap's tile servers which
 use
 planet.osm
 (B) Even if we use our own tile
 server, we cannot fork the planet.osm
 file
 to just change the borders of India. If we do that, we would
 have
 to change the borders every time we
 update planet.osm file.
 
 The
 borders would have to be resolved by consulting with the
 higher
 powers in OSM.
 
 Aditya Nag.
 
 
 On 17/12/2014, Nagarjuna G
 nagar...@gnowledge.org
 wrote:
  On Tuesday 16 Dec 2014 9:04:12
 AM H. S. Sudhira wrote:
  I am sure
 most of you are aware and keeping track of this. Survey of
 India
  / DST takes a step on digital
 maps representing the country's boundary,
  files a complaint against Google! It
 will be interesting to keep a tab on
  this. More troubles to Google, as this
 comes after the Mapathon event!
 
  Here is the official word on this from
 their Facebook post
  https://www.facebook.com/permalink.php?story_fbid=894090357277177id=277739
  112245641fref=nf
 
  It is
 observed that M/s Google Map is wrongly depicting
 external
  boundaries
  of India on maps hosted by them on
 different domains, namely
  http://www.google.cn/maps/@25.7377892,88.726647,4z
 and
  https://www.google.com/maps/@25.1367452,80.1073483,4z
 , which are not
  equivalent to
 Government of India authentication.
 
 The correct official boundaries of India has been shown
 at
  http://www.surveyofindia.gov.in/fil.../Correct_India_Map_1.pdf
  http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.surveyofindia.gov.in%2Ffiles
 
 %2FCorrect_India_Map_1.pdfh=WAQGS5vQhenc=AZNiarC7YaARtZIxN5apmQDyhCrncT0hQ
 
 421xHVoYOMJyElRbJHsUeVdEovbwRg31QZYnJ6Nlxdp-UCqmSLCX3ld8SB53waywyaF2gItaG0Td
 
 ekJc3MYlcWOAa79FSP9FFg_KjEMmyIev-1WTmU3DOW9nPxYwx-2JM6D7QOUkFDVxw
 
  In this
 regard, on the instructions of Department of Science 
 Technology,
  Survey of India has
 officially filled a FIR with SHO, PS Dalanwala,
  Dehradun on 12-12-2014 at 18:00 hrs
 requesting them to take appropriate
 
 legal action against M/s Google Maps for displaying
 incorrect map of
  India.
 
  osm may also get such
 a notice if we get popular.  Let us take the need to
  create a separate server for osm.in
 asap.
 
  --
  GN
 
 
 
 
 ___
  Talk-in mailing list
 
 Talk-in@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-in
 
 
 ___
 Talk-in mailing list
 Talk-in@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-in
 

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

Re: [Talk-in] SoI / DST complain against Google.

2014-12-19 Thread satyaakam goswami

On Fri, Dec 19, 2014 at 9:33 PM, Arun Ganesh arun.plane...@gmail.com
wrote:


 On Fri, Dec 19, 2014 at 8:29 AM, Aditya Nag aditya.nag.2...@gmail.com
 wrote:

 I feel that this problem cannot be solved just by having a separate
 server for OSM India:

 (A) We would most probably be using OpenStreetMap's tile servers which
 use planet.osm

 We will have our own tileserver and our own tile style, which is the whole
 point. The data used is still planet.osm . But the generated tiles are
 customized for India


 (B) Even if we use our own tile server, we cannot fork the planet.osm
 file to just change the borders of India. If we do that, we would have
 to change the borders every time we update planet.osm file.


 The change needs to be done at the map stylesheet. We just need to ignore
 certain border segments so that it is not rendered in the tiles. This is
 very simple to do.



Here is one such proposal from Arun which came up earlier this year
https://wiki.openstreetmap.org/wiki/IN:Proposal

can we just get this done instead of talking about it for years now !

-Satya
Satyaakam.net http://satyaakam.net/ | fossevents.in |
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi

2014-12-19 Thread Simone Cortesi

2014-12-18 23:25 GMT+01:00 Leonardo Frassetto kinetocor...@gmail.com:
 ho aggiunto le informazioni mancanti e dopo una chiaccherata in IRC con il
 DWG, confermo che Wikipedia non può essere usata come fonte. A questo punto,
 non essendo critico come dato attualmente possiamo non metterlo in attesa di
 futuri rilasci di dati compatibili con la licenza Odbl, da parte dello
 Stato.

i CAP sono presenti anche in wikidata e su ckan con licenza Public Domain.

https://www.wikidata.org/wiki/Q6259
http://it.ckan.net/dataset/fsfe-trovacap

-- 
-S

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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-18 23:32 GMT+01:00 Aury88 spacedrive...@gmail.com:

 hai mai sentito qualcuno chiamare un
 cimitero la casa del signore?




in tedesco un'alternativa a Friedhof (~cortile della pace = cimitero) è
Gottesacker (~campo di dio).

Per i cimiteri credo che non avrebbe senso aggiungere il tag
amenity=place_of_worship perché ci sarebbero soltanto svantaggi (sarebbe
più difficile distinguere chiese da cimiteri).

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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-19 0:01 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org:

 Però i luoghi che indichi tu, non sono così /pervasi/ dal culto religioso,
 come i cimiteri.
 Nei cimiteri trovi crocifissi, passi della bibbia, statue di madonne, ecc.
 ecc.
 A casa tua, o nella piazza non ci sono e se ce n'è qualcuna, non in
 quantità come in un cimitero.



se facciamo una domanda quantitativa, allora diventanno anche i souvenir
shop del vaticano luoghi di culto...

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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-19 Thread Daniele Forsi

Il 19 dicembre 2014 00:01, Matteo Quatrida ha scritto:

 Culto dei morti, per l'appunto, che si esegue nel luogo di culto adatto: il
 cimitero.

ma i cimiteri *comunali* non sono automaticamente luoghi di culto
anche se sono pieni di croci

all'interno del cimitero comunale del mio comune c'è una chiesetta
cattolica e secondo me solo quella parte va etichettata come luogo di
culto (lo sarebbe anche se fosse costruita fuori dal cimitero)

-- 
Daniele Forsi

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

Re: [Talk-it] tag rosticceria

2014-12-18 19:20 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org:

 PS. Fanno anche le pizze, quelle spesse...




forno a legno? Allora oven=wood_fired (altrimenti electrical)
http://taginfo.osm.org/keys/oven#values  (non è tra i tags più usati al
momento, ma lo possiamo cambiare insieme).

io ci metterei anche un restaurant:type:it=rosticceria;pizzeria;bar
(se il posto è quello:
http://www.tripadvisor.it/LocationPhotoDirectLink-g187861-d4173964-i76404741-Bar_rosticceria_pizzeria_doppio_zero-Trento_Province_of_Trento_Trentino_A.html
)

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

Re: [Talk-it] tag rosticceria

2014-12-19 Thread Francesca Valentina

Grazie, concordo con chi ha detto che in rosticceria di solito non si
mangia, quelle dovrebbero essere più gastronomie. Anzi le vedo più simili a
gastronomie che ristoranti.
Molto spesso le macellerie hanno rosticcerie. Possiamo proporlo come tag
tipo rosticceria=yes e usarlo come attributo di gastronomia o altri shop ?

Francesca

Il giorno 19 dicembre 2014 14:07, Martin Koppenhoefer 
dieterdre...@gmail.com ha scritto:


 2014-12-18 19:20 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org
 :

 PS. Fanno anche le pizze, quelle spesse...




 forno a legno? Allora oven=wood_fired (altrimenti electrical)
 http://taginfo.osm.org/keys/oven#values  (non è tra i tags più usati al
 momento, ma lo possiamo cambiare insieme).

 io ci metterei anche un restaurant:type:it=rosticceria;pizzeria;bar
 (se il posto è quello:
 http://www.tripadvisor.it/LocationPhotoDirectLink-g187861-d4173964-i76404741-Bar_rosticceria_pizzeria_doppio_zero-Trento_Province_of_Trento_Trentino_A.html
 )

 ciao,
 Martin

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


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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-19 Thread Aury88

Matteo Quatrida-2 wrote
Però i luoghi che indichi tu, non sono così /pervasi/ dal culto
religioso, come i cimiteri.
Nei cimiteri trovi crocifissi, passi della bibbia, statue di madonne,
ecc. ecc.
A casa tua, o nella piazza non ci sono e se ce n'è qualcuna, non in
quantità come in un cimitero.
In un cimitero accendi i ceri, cambi i fiori, ecc. tutto fa parte di un
rituale, il culto dei morti, che è tipico della religione cristiana.
Culto dei morti, per l'appunto, che si esegue nel luogo di culto adatto:
il cimitero.

quello dei morti è solo un espressione del culto uncapitolo ma non è il
culto. e non è li che si fa la celebrazione per il morto ma solo quella
parte riferita alla fase di sepoltura vera e propria...la religione
cristiana prevede che venga compiuto un rituale prima in chiesa e che poi si
dicano le utlime parole all'atto del seppellimento.

ci saranno pure tante croci e tanti ceri ma manca guardacaso il luogo più
importante per la cristianità...il sancta sanctorum...è cioè il tabernacolo
dove, per la religione cristiana, viene conservato il corpo di cristo
tra l'altro fondamentale per portare avanti il più importante tra i rituali
del culto cristiano e cioè la comunione

-
Ciao,
Aury
--
View this message in context:
http://gis.19327.n5.nabble.com/Tag-informativi-aggiuntivi-su-building-tp5827468p5827747.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] dove taggare civici

2014-12-19 Thread Aury88

discorso già uscito diverse volte qua in lista e a questo punto direi che si
dovrebbe impostare il wiki:it con le scelte venute fuori in quelle occasioni
anche perchè è abbastanza complicato risalire a quelle discussioni essendo i
civici un tema ricorrente in molte discussioni anche che originariamente
sono state create per trattare argomenti differenti

in italia non è raro che ad un area si acceda da più entrate e che ognuno di
esse abbia un proprio civico...
a verderio quasi tutti i passi carrabili hanno un numero civico diverso da
quello posto sull'ingresso pedonale.
io mappo così e mi sembra che all'epoca fosse stato genericamente accettato: 
Il numero civico lo metto sul nodo solo se non c'è un civico univoco per
l'area...cioè se in un area si entra da da uno o più ingressi con lo stesso
numero civico o solo un civico esplicitato metto su tutta l'area il tag con
quel civico e poi indico l'ingresso con entrance=main dove esso è posto
se l'area ha più civici metto un nodo in corrispondenza dei punti in cui si
può accedere (entrance barrier=gate etc etc) con associato il tag per il
civico...ho controllato ed entrambi i metodi vengono gestiti correttamente
dai software di navigazione che è il caso di utilizzo principale per questo
genere di dati.

solitamente il recapito postale per un area è uno ed è quello dove è posta
la cassetta delle lettere, ma spesso quella stessa area ha anche altri
ingressi secondari con un proprio civico quindi solitamente e teoricamente
c'è un civico predominante (che non siano palazzine con più ingressi  dotati
di cassetta delle lettere) a cui quindi si riferiscono tutti i poi
all'interno di quell'area  mentre gli altri civici si riferiscono agli
ingressi e penso sia questo il motivo dei comprensibili dubbi di Martin su
come trattare i civici



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/dove-taggare-civici-tp5827571p5827750.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-19 14:45 GMT+01:00 Aury88 spacedrive...@gmail.com:

 ci saranno pure tante croci e tanti ceri ma manca guardacaso il luogo più
 importante per la cristianità...il sancta sanctorum...è cioè il tabernacolo
 dove, per la religione cristiana, viene conservato il corpo di cristo
 tra l'altro fondamentale per portare avanti il più importante tra i rituali
 del culto cristiano e cioè la comunione



credo, ma non sono del tutto sicuro, che questo paragrafo non vale per
tutta la cristianità ma soltanto per i cattolici...
Per esempio nel protestantismo non c'è una comunione e le ostie non sono il
corpo cristo ma soltanto un simbolo per il corpo di cristo.

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

Re: [Talk-it] tag rosticceria


Il 19/12/2014 14:07, Martin Koppenhoefer ha scritto:


2014-12-18 19:20 GMT+01:00 Matteo Quatrida
matteo.quatr...@linuxmail.org mailto:matteo.quatr...@linuxmail.org:

PS. Fanno anche le pizze, quelle spesse...




forno a legno? Allora oven=wood_fired (altrimenti electrical)
http://taginfo.osm.org/keys/oven#values  (non è tra i tags più usati al
momento, ma lo possiamo cambiare insieme).

io ci metterei anche un restaurant:type:it=rosticceria;pizzeria;bar
(se il posto è quello:
http://www.tripadvisor.it/LocationPhotoDirectLink-g187861-d4173964-i76404741-Bar_rosticceria_pizzeria_doppio_zero-Trento_Province_of_Trento_Trentino_A.html
)

ciao,
Martin



E' il posto che hai indicato nel link.


--
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«Be GREEN and keep it on your SCREEN!»

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

Re: [Talk-it] tag rosticceria


Il 19/12/2014 14:11, Francesca Valentina ha scritto:

Grazie, concordo con chi ha detto che in rosticceria di solito non si
mangia, quelle dovrebbero essere più gastronomie. Anzi le vedo più
simili a gastronomie che ristoranti.
Molto spesso le macellerie hanno rosticcerie. Possiamo proporlo come tag
tipo rosticceria=yes e usarlo come attributo di gastronomia o altri shop ?

Francesca



Francesca,

non dobbiamo trascurare la ragione sociale presente sullo scontrino fiscale.

--
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«Be GREEN and keep it on your SCREEN!»

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

Re: [Talk-it] Tag informativi aggiuntivi su building


Il 19/12/2014 13:57, Daniele Forsi ha scritto:

Il 19 dicembre 2014 00:01, Matteo Quatrida ha scritto:


Culto dei morti, per l'appunto, che si esegue nel luogo di culto adatto: il
cimitero.


ma i cimiteri *comunali* non sono automaticamente luoghi di culto
anche se sono pieni di croci

all'interno del cimitero comunale del mio comune c'è una chiesetta
cattolica e secondo me solo quella parte va etichettata come luogo di
culto (lo sarebbe anche se fosse costruita fuori dal cimitero)



Secondo me ci stiamo perdendo in sottigliezze...
Considera comunque che il /culto dei morti/ lo si fa anche esternamente 
alla cappella.


--
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«Be GREEN and keep it on your SCREEN!»

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

Re: [Talk-it] Tag informativi aggiuntivi su building


Il 19/12/2014 14:45, Aury88 ha scritto:

quello dei morti è solo un espressione del culto uncapitolo ma non è il
culto. e non è li che si fa la celebrazione per il morto ma solo quella
parte riferita alla fase di sepoltura vera e propria...la religione
cristiana prevede che venga compiuto un rituale prima in chiesa e che poi si
dicano le utlime parole all'atto del seppellimento.

ci saranno pure tante croci e tanti ceri ma manca guardacaso il luogo più
importante per la cristianità...il sancta sanctorum...è cioè il tabernacolo
dove, per la religione cristiana, viene conservato il corpo di cristo
tra l'altro fondamentale per portare avanti il più importante tra i rituali
del culto cristiano e cioè la comunione



Quindi se ti porto la foto di un cimitero con il sancta sanctorum in 
mezzo, allora sono autorizzato a mettere amenity=place_of_worship?


--
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«Be GREEN and keep it on your SCREEN!»

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

Re: [Talk-it] Tag informativi aggiuntivi su building

2014-12-19 Thread Aury88

Matteo Quatrida-2 wrote
 Quindi se ti porto la foto di un cimitero con il sancta sanctorum in 
 mezzo, allora sono autorizzato a mettere amenity=place_of_worship?

...questa tua frase mi lascia perplesso...come se ad un certo punto ti
avessi dato l'idea che serva la mia autorizzazione (a seguito di prova
fotografica poi)  per inserire qualcosa su osm...mi sembrava si stesse
discutendo tranquillamente su cosa secondo noi fosse un place of worship e
cosa ni, ma se ti ho dato l'idea che servisse la mia autorizzazione me ne
scuso e mi correggo dicendoti che non è assolutamente così.

Vediamo comunque questa immagine così forse capisco cosa intendi...
Il tabernacolo è un ottimo indice di un luogo usato per funzioni religiose
ma bisognerebbe valutare anche alcune cose e cioè se viene utilizzato e in
che maniera...la fede cristiana-cattolica prevede che vengano eseguite delle
messe obbligatorie durante un giorno specifico della settimana, e di
conseguenza il culto prevede che venga svolto almeno un rituale a
settimana...identificare il luogo dove quindi si celebrano le messe ogni
settimana o al limite frequentemente e in alternanza con altri di culto è un
ottimo modo per identificare i luoghi dove viene portato avanti il culto
religioso. Questi riti nella religione cristiano-cattolica prevedono delle
letture, una loro spiegazione, la comunione  e altre parti che nell'insieme
compongono la messa...
Tornando al tabernacolo esso è all'interno di una struttura o all'aperto? in
quest'ultimo caso c'è un area precisa e/o delimitata in cui si svolge il
rituale e dove si raccolgono i fedeli o si estende senza un particolare
limite e ed eventualmente su tutta l'area del cimitero? in quest'ultimo caso
potrebbe starci bene effettivamente il place of worship altrimenti
bisognerebbe valutare caso per caso...il mondo è troppo vario per escludere
a priori qualsiasi possibilità
Io, di fronte ad un cimitero usato comunemente solo per seppellire i defunti
e per tutti i rituali annessi, ho sempre dato per scondato (probabilmente
sbagliando) che tali rituali fossero insiti nella natura della funzione di
un cimitero (sopratutto se con una connotazione religiosa)...in qui quindi
un place of worship, seppur non propriamente errato è in realtà ridondante
con la definizione di cimitero e allo stesso tempo il cimitero non è di per
se il luogo di culto almeno per la religione cristiana...avrei immaginato
che un cimitero potesse essere un effettivo luogo di culto (e indicato come
tale) per quelle religioni particolarmente incentrate attorno la figura dei
defunti (visti come spiriti protettori, intermediari eo destinatari ultimi
delle preghieree chissà cos'altro) e i cui riti quindi si svolgono per la
maggior parte proprio nel luogo di sepoltura.
comunque sia ci sono delle ottime pagine wiki che, sicuramente meglio di me,
potrebbero chiarire meglio cosa e quali siano i luoghi di culto e cosa no e
magari confermare o smentire ciò che affermo io; Si protrebbe dare uno
sguardo per cominciare a http://en.wikipedia.org/wiki/Place_of_worship e
http://en.wikipedia.org/wiki/Cemetery e poi decidere se quello che
definiscono loro per noi vada bene.





-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Tag-informativi-aggiuntivi-su-building-tp5827468p5827800.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-dk] Flytning af ny adressepunkter

2014-12-19 Thread Lars Gravengaard

Hej Michael

Jeg hat tænkt lidt over dette :-)

et resultat af at de officielle adresser også er blevet smidt på et sted

Adresser er jo placeret rigtigt på danmarksadresser.dk. Er de ikke de
officielle i danmark ?

Lars


2014-12-16 23:01 GMT+01:00 Michael Andersen hj...@milvus.dk:

 Hej Lars

 Det forekommer mange steder og er et resultat af at de officielle adresser
 også
 er blevet smidt på et sted. Jeg kan ikke lige huske om vi umiddelbart kan
 gøre
 noget ved det. Mange af de tilfælde jeg tidligere er stødt på er gradvist
 blevet ordnet.

 Tirsdag den 16. december 2014 22:44:58 skrev Lars Gravengaard:
  Hej
 
  Da jeg kontrollere om vejnavn ændringen var lavet ved
  Havekolonien Fjordglimt i Struer
  https://www.openstreetmap.org/changeset/27516910.
 
  Kunne jeg se at bruger AWSbot i ændringssæt
  https://www.openstreetmap.org/changeset/26895652
 
  Har placeret alle adresser i samme punkt ! Normat siges det jo at vi ikke
  må ændre på de punker som bot automatisk laver. Så hvad kan jeg gøre nu ?
 
  Vh
  Lars


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

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

Re: [Talk-gb-westmidlands] Work about to start at Paradise Circus, Birmingham

2014-12-19 Thread Brian Prangle

Thanks for this Andy- as I read the info there are just road closures
immediately so no need to do anything to the map until demolition starts
and the tunnel part of the gyratory gets permanently removed from the
network physically

Rgds Brian

On Wed, Dec 17, 2014 at 11:51 AM, Andy Robinson ajrli...@gmail.com wrote:

 Heads up. Work due to start immediately in the new year on the Paradise
 Circus redevelopment. This includes the removal of the current gyratory.
 Details via the link below. I also have some other details as a result of
 some briefing notes.

 http://www.paradisebirmingham.co.uk/access/

 Cheers
 Andy


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

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

Re: [Talk-gb-westmidlands] Work about to start at Paradise Circus, Birmingham

2014-12-19 Thread Andy Robinson

Before the main development happens there is lots of enabling works which 
includes road closures which will be in place for quite some time. The first 
batch programmed I understand are:

10th or 12th January – Summer Row closed between Lionel Street and Great 
Charles Street. Period of closure unclear.

19th January -  Exit from Paradise Circus onto Summer Row/Sandpits will close.

31st January – Broad Street Restrictions - buses and Hackney Carriages only 
permitted inbound from Bridge Street to the Circus

 

Cheers

Andy

 

From: Brian Prangle [mailto:br...@mappa-mercia.org] 
Sent: 19 December 2014 08:46
To: Andy Robinson
Cc: talk-gb-westmidlands
Subject: Re: [Talk-gb-westmidlands] Work about to start at Paradise Circus, 
Birmingham

 

Thanks for this Andy- as I read the info there are just road closures 
immediately so no need to do anything to the map until demolition starts and 
the tunnel part of the gyratory gets permanently removed from the network 
physically

Rgds Brian

 

On Wed, Dec 17, 2014 at 11:51 AM, Andy Robinson ajrli...@gmail.com wrote:

Heads up. Work due to start immediately in the new year on the Paradise
Circus redevelopment. This includes the removal of the current gyratory.
Details via the link below. I also have some other details as a result of
some briefing notes.

http://www.paradisebirmingham.co.uk/access/

Cheers
Andy


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

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4794 / Virus Database: 4235/8761 - Release Date: 12/18/14

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

[Talk-gb-westmidlands] FW: [Talk-GB] Post-Christmas Midlands OSM Meet-up

2014-12-19 Thread Andy Robinson

From: SK 53 (via Doodle) [mailto:mai...@doodle.com] 
Sent: 19 December 2014 20:37
To: talk...@openstreetmap.org
Subject: [Talk-GB] Post-Christmas Midlands OSM Meet-up

SK 53 invites you to participate in the Doodle poll Post-Christmas Midlands 
OSM Meet-up.

https://doodle.com/?tmail=poll_invitecontact_participant_invitation_with_messagetlink=logo

Hi there, 

SK 53 (sk53@gmail.com) invites you to participate in the Doodle poll 
Post-Christmas Midlands OSM Meet-up. 

SK 53 says: 

Idea is to meet somewhere accessible to both EW Midland OSMers in the week 
after Xmas. The meeting would be in the day time, with the idea of initially 
surveying some rights of way (or just their designations), adjourning to a pub 
for a drink and/or lunch. Possible areas mentioned are: Foxton (Leics), near 
Burton (perhaps Barton, or Abbots Bromley), Muston (Leics). Final location will 
really depend on interest  maximising convenience for participants.

Suggested start time is 10:30, but 11:00 may suit better.

Any other suggestions etc, reply to talk-gb.

Note I'm a newbie at setting up a Doodle poll, so apologies if this is all 
askew!

Jerry 

https://doodle.com/47ey64h55fa52dtt?tmail=poll_invitecontact_participant_invitation_with_messagetlink=pollbtn
 Participate now 

  http://doodle.com/graphics/mails0/info.png 

What is Doodle? Doodle is a web service that helps SK 53 to find a suitable 
date for meeting with a group of people. Learn more about how Doodle works. 
https://doodle.com/main.html?tlink=checkOutLinktmail=poll_invitecontact_participant_invitation_with_message

You have received this e-mail because SK 53 has invited you to participate in 
the Doodle poll Post-Christmas Midlands OSM Meet-up. 

Doodle AG, Werdstrasse 21, 8021 Zürich 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4794 / Virus Database: 4235/8761 - Release Date: 12/18/14

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

Re: [Talk-es] Resumen de Talk-es, Vol 95, Envío 5

2014-12-19 Thread Wladimir Szczerban

Hi Tom,
You can download the data without certificate if you know the url.

The URL has the following structure
http://www.catastro.minhap.es/INSPIRE/CadastralParcels/CODIGO_PROVINCIA/CODIGO_MUNICIPIO-NOMBRE_MUNICIPIO.ES.SDGC.CP.U.CODIGO_MUNICIPIO.zip

You can see Cadastral services for provincial codes and the names and codes
of town on the following link
https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCallejero.asmx

Examples

Urban cartography
http://www.catastro.minhap.es/INSPIRE/CadastralParcels/25/25001-ABELLA%20DE%20LA%20CONCA/A.ES.SDGC.CP.U.25001.zip

Rustic cartography
http://www.catastro.minhap.es/INSPIRE/CadastralParcels/25/25001-ABELLA%20DE%20LA%20CONCA/A.ES.SDGC.CP.R.25001.zip

Here you can see a manual for loading data into Qgis
http://www.geoportal-idec.cat/geoportal/cat/documentacio/manuals/Manual_Visor_GML_cat.pdf

Saludos,
Wladimir


2014-12-13 13:00 GMT+01:00 talk-es-requ...@openstreetmap.org:

 Envíe los mensajes para la lista Talk-es a
 talk-es@openstreetmap.org

 Para subscribirse o anular su subscripción a través de la WEB
 https://lists.openstreetmap.org/listinfo/talk-es

 O por correo electrónico, enviando un mensaje con el texto help en
 el asunto (subject) o en el cuerpo a:
 talk-es-requ...@openstreetmap.org

 Puede contactar con el responsable de la lista escribiendo a:
 talk-es-ow...@openstreetmap.org

 Si responde a algún contenido de este mensaje, por favor, edite la
 linea del asunto (subject) para que el texto sea mas especifico que:
 Re: Contents of Talk-es digest Además, por favor, incluya en la
 respuesta sólo aquellas partes del mensaje a las que está
 respondiendo.


 Asuntos del día:

1. access to Spanish cadastre (Tom Lee)
2. Re: access to Spanish cadastre (Agustín)
3. Re: access to Spanish cadastre (Cruz Enrique Borges Hernandez)


 --

 Message: 1
 Date: Fri, 12 Dec 2014 13:33:57 -0500
 From: Tom Lee t...@mapbox.com
 To: talk-es@openstreetmap.org
 Subject: [Talk-es] access to Spanish cadastre
 Message-ID:
 
 caeuyxdtnarsgx_nmp+40xbpekefhtmxheerxj4jq_brcu7s...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 I've recently been researching Spain's cadastral database, which quickly
 led to the work done on cat2osm and other projects by people on this list.
 However, I find myself confused. I believe that links to bulk downloads of
 the data exist on this page:

 https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv

 In fact, it is discussed in some detail on this OSM wiki page:

 http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro

 But when I attempt a download, it seems that I need an X.509 certificate. I
 wonder if anyone can explain the nature of this requirement o a non-Spanish
 citizen? I realize that some elements of the database related to land value
 and ownership are sensitive, but I don't believe that these bulk downloads
 include such data. The license terms associated with this data seem to be
 quite open (

 http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf
 ), which makes this requirement all the more confounding.

 Any insights are much appreciated.

 Tom
  próxima parte 
 Se ha borrado un adjunto en formato HTML...
 URL: 
 http://lists.openstreetmap.org/pipermail/talk-es/attachments/20141212/766a93fd/attachment-0001.html
 

 --

 Message: 2
 Date: Fri, 12 Dec 2014 20:15:46 +0100
 From: Agustín agustind...@gmail.com
 To: Discusión en Español de OpenStreetMap
 talk-es@openstreetmap.org
 Subject: Re: [Talk-es] access to Spanish cadastre
 Message-ID: 082722c4-ef69-4af6-b8a2-339bf6a54...@gmail.com
 Content-Type: text/plain; charset=utf-8


  On 12 Dec 2014, at 19:33, Tom Lee t...@mapbox.com wrote:
 
  I've recently been researching Spain's cadastral database, which quickly
 led to the work done on cat2osm and other projects by people on this list.
 However, I find myself confused. I believe that links to bulk downloads of
 the data exist on this page:
 
  https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv 
 https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv
 
  In fact, it is discussed in some detail on this OSM wiki page:
 
  http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro 
 http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro
 
  But when I attempt a download, it seems that I need an X.509
 certificate. I wonder if anyone can explain the nature of this requirement
 o a non-Spanish citizen? I realize that some elements of the database
 related to land value and ownership are sensitive, but I don't believe that
 these bulk downloads include such data. The license terms associated with
 this data seem to be quite open (
 http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 19.12.2014 09:31, Martin Vonwald wrote:
 Da die Nutzung von maxspeed:variable kontinuierlich ansteigt, möchte ich
 euch nochmals auf das entsprechende Proposal hinweisen:
 https://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed
 
 Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
 überlegen, da es nicht nur die Information liefert, dass das
 Geschwindigkeitslimit variabel ist, sondern zusätzlich:
 * das höchste mögliche(!) Geschwindigkeitslimit
 * den Grund(!) für das variable Limit
 
 Ich halte beides für potentiell wertvolle Information für Datenkonsumenten.
 
 Beispiel: Auf Autobahnen in Österreich gilt üblicherweise ein
 Geschwindigkeitslimit von 130 km/h. Autobahnen, welche größere Städte
 durchqueren, verfügen jedoch häufig über ein variables Limit und recht
 häufig ist das maximale Limit 80km/h. 130km/h oder 80 km/h ist ein
 ziemlicher Unterschied. Wenn wir nur die Information liefern, dass das Limit
 variabel ist, welches Limit soll ein Datenkonsument annehmen? Vielleicht ist
 es schneller die Stadt zu umfahren, da dort normalerweise 130 km/h gilt?
 
 
 Ich möchte vorschlagen die Empfehlung zu maxspeed=signals aus dem Wiki zu
 entfernen und stattdessen auf maxspeed:variable=Grund + maxspeed=maximal
 mögliches Limit zu verweisen.

maxspeed=signals wird über 5000x verwendet, ist also in use und muss daher
im Wiki dokumentiert bleiben. Es liegt ungefähr gleich auf mit
maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir...

Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es
einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine
Veränderung oder Diskussion mehr an diesem Proposal.

Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
maxspeed=signals allein fehlt die Information über die Maximal- bzw.
Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen
mir ebenfalls nicht. Ursprünglich war nur =yes vorgesehen, und solche Tags
weisen immer darauf hin, dass der Key besser ein Value sein sollte.

Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist
ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. Bitte
dem Grundsatz we map what we see treu bleiben. Auf der A2 und der
Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel Verkehr
herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern...

Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals
Der Wert signals impliziert schon, dass sich die Anzeige ändern kann.

Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag
eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80. Aber das
neue Tag müsste dann halt den Routern beigebracht werden. Grundsätzlich
entspricht maxspeed=signals dem Ansatz maxspeed=code (z.B.
maspeed=AT:urban), der in AT eher ungebräuchlich ist.

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

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

2014-12-19 Thread Martin Vonwald

Am 19. Dezember 2014 um 11:44 schrieb Friedrich Volkmann b...@volki.at:

 maxspeed=signals wird über 5000x verwendet, ist also in use und muss
 daher
 im Wiki dokumentiert bleiben.


Wo habe ich das Gegenteil behauptet?



 Es liegt ungefähr gleich auf mit
 maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir...


Nette Unterstellung. Leider mappe ich schon seit ewigen Zeiten praktisch
nichts, trotzdem steigen die Zahlen kontinuierlich. Die neuen Zahlen habe
ich heute auf meiner Watchlist entdeckt.



 Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es
 einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine
 Veränderung oder Diskussion mehr an diesem Proposal.


Ich glaube nicht an Abstimmungen, wo 10-20 Leute meinen, darüber
entscheiden zu können, was tausende Mapper zu tun oder zu lassen haben. Was
der Autor machen will oder nicht, sei ihm überlassen.



 Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
 maxspeed=signals allein fehlt die Information über die Maximal- bzw.
 Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
 die Geschwindigkeit angezeigt wird.


Durch ein Zusatztag jederzeit zu ergänzen. Du darfst gerne eines
vorschlagen.



 Die Werte von maxspeed:variable=* taugen
 mir ebenfalls nicht.


Ausgezeichnetes Argument. Gut begründet und umfangreiche Lösungsvorschläge.



 Ursprünglich war nur =yes vorgesehen, und solche Tags
 weisen immer darauf hin, dass der Key besser ein Value sein sollte.


Ursprünglich = Vergangenheit.



 Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist
 ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird.


Mapper vor Ort sollten den Hauptgrund wissen.



 Bitte
 dem Grundsatz we map what we see treu bleiben. Auf der A2 und der
 Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel
 Verkehr
 herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern...


No na net! Da fällt mir jetzt nur die Signatur von jemandem aus dem Forum
ein: Kopf - Tisch - bumms. Und wenn ein UFO dort landet, dann wird die A2
sogar komplett gesperrt!



 Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals
 Der Wert signals impliziert schon, dass sich die Anzeige ändern kann.


Niemand hindert dich daran, dieses Zusatztag zu verwenden.


Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag
 eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80.


max_maxspeed? ...


Aber das
 neue Tag müsste dann halt den Routern beigebracht werden.


Man könnte natürlich auch auf die komplett abwegige Idee kommen, ein Tag
einfach immer für das selbe zu verwenden.


Danke für deinen Beitrag.
Martin
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 12/19/2014 09:31 AM, Martin Vonwald wrote:
 Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
 überlegen, da es nicht nur die Information liefert, dass das
 Geschwindigkeitslimit variabel ist, sondern zusätzlich:
 * das höchste mögliche(!) Geschwindigkeitslimit
 * den Grund(!) für das variable Limit

Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL.
Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit
die angezeigt werden kann, kann ich mir als normaler Mapper, der selten
Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen
sollen. Werden da dann Verordnungstexte in OSM eingepflegt oder wie kann
ich als Gelegenheitsmapper auf einer Autobahn feststellen, was denn hier
die richtige Geschwindigkeit ist? Ich kann mich nämlich nicht dran
erinnern in letzter Zeit noch irgendwo Stahlschilder neben Signalanlagen
gesehen zu haben.

Ich versteh den Grund warum die Daten drin sein sollen, aber für mich
schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort
nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas
Bauchweh.

Norbert

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 19.12.2014 11:46, Martin Vonwald wrote:

 Es liegt ungefähr gleich auf mit
 maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von 
 dir...
 
 Nette Unterstellung. Leider mappe ich schon seit ewigen Zeiten praktisch
 nichts, trotzdem steigen die Zahlen kontinuierlich. Die neuen Zahlen habe
 ich heute auf meiner Watchlist entdeckt.

Auch wenn es länger her ist, sind viele von dir. Z.B. an
http://www.openstreetmap.org/way/35593053/history sieht man, wie du meine
maxspeed=signals auf die andere Variante geändert hast - ohne es mit mir
oder mit der Community abzusprechen. Und auch wie du das Deppenleerzeichen
eingefügt hast - ebenfalls ohne das mit dem ursprünglichen Mapper oder der
Community abzusprechen. Und durch die unzähligen Splits fürs dein
Spurmapping - bei dem du nicht existierende bauliche Trennungen eingefügt
hast, wieder ohne das mit irgendwem abzusprechen - haben sich die Anzahl
Ways mit maxspeed:variable=* vervielfacht. Wenn man deine Änderungen
wegrechnet, ist maxspeed=signals noch klar vorne.

 Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es
 einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine
 Veränderung oder Diskussion mehr an diesem Proposal.
 
 Ich glaube nicht an Abstimmungen, wo 10-20 Leute meinen, darüber entscheiden
 zu können, was tausende Mapper zu tun oder zu lassen haben. Was der Autor
 machen will oder nicht, sei ihm überlassen.

Das sehe ich auch so. Aber alles umtaggen ohne irgendeine Legitimation dafür
zu haben ist noch schlimmer.

 Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
 maxspeed=signals allein fehlt die Information über die Maximal- bzw.
 Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
 die Geschwindigkeit angezeigt wird. 
 
 Durch ein Zusatztag jederzeit zu ergänzen. Du darfst gerne eines vorschlagen.

Kein Bedürfnis, da ich maxspeed:type=signals sowieso bevorzuge.

 Die Werte von maxspeed:variable=* taugen
 mir ebenfalls nicht.
 
 Ausgezeichnetes Argument. Gut begründet und umfangreiche Lösungsvorschläge.

Mein Lösungsvorschlag ist, maxspeed:type=signals statt maxspeed:variable=*
zu verwenden.

 Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist
 ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. 
 
 Mapper vor Ort sollten den Hauptgrund wissen.

Vor Ort sieht man nur eine Anzeigetafel, und auf der steht normalerweise nur
eine Geschwindigkeitsbeschränkung, oder sie ist überhaupt inaktiv.

 Bitte
 dem Grundsatz we map what we see treu bleiben. Auf der A2 und der
 Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel 
 Verkehr
 herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern...
 
 No na net! Da fällt mir jetzt nur die Signatur von jemandem aus dem Forum
 ein: Kopf - Tisch - bumms. Und wenn ein UFO dort landet, dann wird die A2
 sogar komplett gesperrt!

Wenn für dich so offensichtlich ist, dass das Limit in vielen verschiedenen
Fällen herabgesetzt wird, warum hast du dann auf der A2 fälschlich
maxspeed:variable=peak_traffic gesetzt?

 Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals
 Der Wert signals impliziert schon, dass sich die Anzeige ändern kann.
 
 Niemand hindert dich daran, dieses Zusatztag zu verwenden.

Ok, dann tagge ich alle (sowieso falschen, s.o.)
maxspeed:variable=peak_traffic auf der A2 und A22 auf maxspeed:type=signals
um. Irgendwer dagegen?

 Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag
 eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80. 
 
 max_maxspeed? ...

Bitte verbaler. Was willst du wissen?

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

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x


Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich
überlegen, da es nicht nur die Information liefert, dass das
Geschwindigkeitslimit variabel ist, sondern zusätzlich:
* das höchste mögliche(!) Geschwindigkeitslimit
* den Grund(!) für das variable Limit


Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL.
Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit
die angezeigt werden kann, kann ich mir als normaler Mapper, der selten
Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen
sollen.
[...] als wären das Daten, die ein Mapper vor Ort
nicht mehr einfach nachvollziehen kann.


Natürlich sind die Daten (der Hauptgrund für Änderung der 
Geschwindigkeit) Vor-Ort durch Beobachtung überprüfbar, nur nicht bei 
einem einzelnen Kurzbesuch. Aber praktisch jeder Ortskundige oder 
Berufsfahrer kann die Daten bestätigen, immerhin stehen die Dinger ja 
auf Hauptverkehrsrouten und nicht auf Feldwegen, wo wir schon froh sind, 
wenn da überhaupt 'mal ein Mapper vorbeikommt.


Im übrigen bleibt der Wert yes als Option, wenn man eine neue Anlage 
einträgt und nicht ortskundig ist.


Die fehlende Überprüfbarkeit bei einem einzelnen Besuch gilt im übrigen 
auch für highway=primary, secondary, tertiary, das kann man ohne 
Ortskenntnisse Vor-Ort (zB bei einem Sonntagsbesuch in einem ländlichen 
Ort als Gelegenheitsmapper) auch nicht wirklich überprüfen. 
Ortskundigkeit wird bei manchen Tags in OSM benötigt.


Aus meiner Sicht gibt es genügend Mapper - viel mehr als bei manch 
anderen Tags - die gemachte Angaben verifizieren können, daher ist doch 
eher eine akademische Diskussion über Regeln, die solche Projekte oft 
ersticken. In einem Community-Projekt benötigt es auch manchmal 
Pragmatismus, am Ende zählt doch ob falsche Daten durch genügend Mapper 
erkannt werden können -- und das ist hier aus meiner Sicht gegeben.


martinq

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 12/19/2014 02:37 PM, martinq wrote:
 Aus meiner Sicht gibt es genügend Mapper - viel mehr als bei manch
 anderen Tags - die gemachte Angaben verifizieren können, daher ist doch
 eher eine akademische Diskussion über Regeln, die solche Projekte oft
 ersticken. In einem Community-Projekt benötigt es auch manchmal
 Pragmatismus, am Ende zählt doch ob falsche Daten durch genügend Mapper
 erkannt werden können -- und das ist hier aus meiner Sicht gegeben.

Wenn wir hier von Pragmatismus reden, warum wird dann die
Höchstgeschwindigkeit erfasst, die die Signalanlage erlaubt? Zugegeben,
ich fahr nicht viel Auto, aber mir fallen da durchaus Abschnitte ein, da
kommt die tatsächlich einstellbare Höchstgeschwindigkeit praktisch nie
zum Zug. Wäre es da nicht sinnvoller, wenn es die Community dafür gibt,
die das korrekt und richtig mapped, die erwartbare Geschwindigkeit zu
mappen? Was interessiert mich denn die mögliche Höchstgeschwindigkeit,
wenn die an vermutlich nichtmal an einem Drittel der Tage im Jahr
erreicht wird?

Also unabhängig davon, ob das jetzt gut zu mappen ist, hielt ich es für
sinnvoller, wenn schon die Community das ordentlich beurteilen kann, was
die Signalanlagen anzeigen, das wahrscheinliche Limit zu mappen (und ev.
den Bereich den sie normalerweise signalisieren). Ob mir das Navi als
Limit jetzt autobahn:max oder signalanlage:max anzeigt, ist mir dann
ehrlich gesagt egal wenn ich zu schnell bin oder meine Route über eine
Autobahn geplant wurde, die zwar theoretisch höhere Geschwindigkeiten
erlaubt, es aber praktisch nur selten auch erlaubt ist.

Wenn also fuzzy Daten erfasst werden, weil es genug Leute gibt die das
brauchen und erfassen können, dann sollten die Ergebnisse aber auch das
widerspiegeln und nicht nur den möglichen Fehler verkleinern sondern ihn
gleich minimieren, indem die wahrscheinlichste Geschwindigkeit angegeben
wird, nicht die wahrscheinlich maximal erlaubte.

Norbert


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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x


maxspeed=signals wird über 5000x verwendet, ist also in use und muss daher
im Wiki dokumentiert bleiben.


+1


Es liegt ungefähr gleich auf mit
maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir...


Schon die geografische Verbreitung spricht dagegen: 
https://taginfo.openstreetmap.org/keys/maxspeed%3Avariable#map
Das steht schon auf etwas breitere Basis, maxspeed=signals war bei 
vielen nicht sonderlich beliebt, daher wird der Vorschlag auch gerne 
übernommen.



Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es
einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine
Veränderung oder Diskussion mehr an diesem Proposal.


Ja, der korrekte Weg - nach geltenden Richtlinien - wäre eine Abstimmung 
und anschließend die Änderung der maxspeed-Seite mit dem Hinweis, dass 
maxspeed=signals als veraltet gilt. Die RFC-Phase gab's ja schon.


Das Alter eines Proposals oder dessen letzte Änderung sagt hingegen nix 
über Akzeptanz und Verbreitung aus.



Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
maxspeed=signals allein fehlt die Information über die Maximal- bzw.
Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen
mir ebenfalls nicht.


Also ich sehe schon einen bedeutenden Unterschied, ob die Information 
über die Maximalgeschwindigkeit in einem Tag für die 
Maximalgeschwindigkeit fehlt oder ob eine nebensächliche Information, 
wie etwas angezeigt wird (LED, Prismawender?) fehlt. Wenn es 
Interessenten für die Art der Anzeige gibt, dann würde ich 
maxspeed:variable:type=led,prism,etc vorschlagen.



Ursprünglich war nur =yes vorgesehen, und solche Tags
weisen immer darauf hin, dass der Key besser ein Value sein sollte.


-1

In manchen Fällen gibt yes diesen Hinweis vielleicht, immer aber 
sicher nicht. Ich erinnere zB an oneway=yes.
Anstelle von yes tritt bei vielen Tags öfters eine zusätzliche 
Hauptinformation, statt highway=yes (das ist eine Straße) hat man sich 
dazu entschieden, die Bedeutung zu integrieren (mit den OSM-üblichen 
Zusatz-Hacks). Bei maxspeed:variable ist eben der Vorschlag, statt yes 
direkt einen Hinweis über den Grund und damit implizit über die 
Häufigkeit zu geben. maxspeed:variable unterscheidet sich daher vom 
Konzept nicht von vielen anderen etablierten OSM-Tags.



Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist
ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. Bitte
dem Grundsatz we map what we see treu bleiben. Auf der A2 und der
Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel Verkehr
herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern...


Nicht alle Gründe sondern primär der Hauptgrund. Der ist bei der 
Tangente offensichtlich peak_traffic und diese Information kann jeder 
Ortskundige (in diesem Fall - und generell bei Hauptverkehrswegen mit 
Verkehrsbeeinflussung - sehr viele) bestätigen.



Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals
Der Wert signals impliziert schon, dass sich die Anzeige ändern kann.


Ich kann jetzt - außer den unterschiedlichen Bezeichnern - keinen 
inhaltlichen Unterschied zwischen

maxspeed=80 + maxspeed:type=signals
und dem vorgeschlagenen
maxspeed=80 + maxspeed:variable=yes
erkennen.

Nur lässt maxspeed:variable eben Raum gleich direkt für detaillierte 
Angaben - wenn man so will. Das entspricht einem lange gebräuchlichen 
Ansatz in OSM. Natürlich hätte man auch maxspeed:variable=prism, 
maxspeed:variable=led, etc nehmen können, aber ein Hinweis auf die 
Häufigkeit (nur fallweise, meistens der gleiche Wert oder tägliche 
Änderung bei peak_traffic) wurde als die wichtigere Information erachtet.



Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag
eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80.


Möglich, aber sinnvoller wäre es, den Murks zu beseitigen, dass im Tag 
für die maximale Höchstgeschwindigkeit genau diese Information nicht zu 
finden ist. Wir reden hier von einer Schlüssel/Wert-Kombination, die 
noch nicht millionenfache Verbreitung gefunden hat, daher ist aus meiner 
Sicht die geplante Umstellung vertretbar.


Im übrigen hatte maxspeed=signal schon schlechte Akzeptanz, viele 
Tunnelstrecken mit variabler Anzeige waren einfach mit der zu 99% 
geltenden Geschwindigkeit und nicht mit signals gekennzeichnet. Die 
neue Möglichkeit legalisiert diesen Ansatz und erlaubt es, die 
signals-Information nun trotzdem zu taggen.


Gruß
martinq

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 19.12.2014 15:49, martinq wrote:
 Es liegt ungefähr gleich auf mit
 maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir...
 
 Schon die geografische Verbreitung spricht dagegen:
 https://taginfo.openstreetmap.org/keys/maxspeed%3Avariable#map

Wieso, da sieht man doch, dass alles auf DE, AT und Südostengland
konzentriert ist. Sonst sind nur einzelne Punkte.

Einzelne Mapper können in dieser Karte schnell größere rote Flächen
erzeugen. Schau dir z.B. die Karte für maxspeed:type=* an. Da entstand ein
riesen roter Fleck, nur weil ich in letzter Zeit in NÖ maxspeed:type=* statt
source:maxspeed=* verwende.

 Das Alter eines Proposals oder dessen letzte Änderung sagt hingegen nix über
 Akzeptanz und Verbreitung aus.

Aber es sagt was darüber aus, ob es reif für die Abstimmung ist. Ich mag es
nicht, wenn ein Proposal nur 2 Wochen lang RFC ist und dann schon abgestimmt
wird. Das ist Überrumpelungstaktik. In Fall von maxspeed:variable=* besteht
das Proposal schon lang genug, es hatte jeder genug Zeit sich an der
Diskussion zu beteiligen (auch wenn ich es nicht getan habe, Asche auf mein
Haupt). Darum gibt es keinen Grund, noch länger zuzuwarten.

 Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
 maxspeed=signals allein fehlt die Information über die Maximal- bzw.
 Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
 die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen
 mir ebenfalls nicht.
 
 Also ich sehe schon einen bedeutenden Unterschied, ob die Information über
 die Maximalgeschwindigkeit in einem Tag für die Maximalgeschwindigkeit fehlt
 oder ob eine nebensächliche Information, wie etwas angezeigt wird (LED,
 Prismawender?) fehlt. Wenn es Interessenten für die Art der Anzeige gibt,
 dann würde ich maxspeed:variable:type=led,prism,etc vorschlagen.

maxspeed=* steht eigentlich nicht für die Maximalgeschwindigkeit, sondern
für die Geschwindigkeitsbeschränkung. Wenn du in dem Tag genau das drin
haben willst, musst du eigentlich maxspeed=signals bevorzugen. maxspeed=80
ist falsch, wenn die Geschwindigkeitsbeschränkung nicht immer 80 ist.

Die Information, wie eine Geschwindigkeitsbeschränkung vermittelt wird, ist
vielleicht für Router nicht wichtig, für andere Anwendungen und vor allem
für die Wart- und Überprüfbarkeit der Daten sehr wohl. Darum gibt es dafür
schon länger source:maxspeed=* bzw. synonym maxspeed:type=*. Und genau da
passt nun auch der Wert signals hinein. Ob die Anzeige auf LED oder Prisma
basiert, darum geht es mir nicht, denn das ist so bedeutsam wie ob ein
Verkehrszeichen auf einer Alu- oder einer Eisenstange steht. ;-)

 Ursprünglich war nur =yes vorgesehen, und solche Tags
 weisen immer darauf hin, dass der Key besser ein Value sein sollte.
 
 -1
 
 In manchen Fällen gibt yes diesen Hinweis vielleicht, immer aber sicher
 nicht. Ich erinnere zB an oneway=yes.
 Anstelle von yes tritt bei vielen Tags öfters eine zusätzliche
 Hauptinformation, statt highway=yes (das ist eine Straße) hat man sich dazu
 entschieden, die Bedeutung zu integrieren (mit den OSM-üblichen
 Zusatz-Hacks). Bei maxspeed:variable ist eben der Vorschlag, statt yes
 direkt einen Hinweis über den Grund und damit implizit über die Häufigkeit
 zu geben. maxspeed:variable unterscheidet sich daher vom Konzept nicht von
 vielen anderen etablierten OSM-Tags.

oneway=yes war als Flag gedacht. Entweder ist es eine Einbahn oder nicht.
Entweder ist der Tisch rund oder nicht. Aber seit man draufgekommen ist,
dass oneway=-1 nötig werden kann, muss man sich fragen, ob ein Tag wie
driving_direction=forward/backward/both nicht verständlicher wäre.

Das ist noch harmlos gegen die unzähligen fuel:*=*. Deren Anzahl steigt
immer weiter. Ein einziger Key könnte die alle ersetzen, z.B.
fuel=octane95;diesel. Das hätte man eigentlich schon vorher wissen müssen.

maxspeed:variable=yes ist ebenfalls ein Flag, das gleichbedeutend mit
irgendwas=variable angegeben werden könnte, z.B. maxspeed=variable oder
maxspeed:type=variable.

maxspeed:variable=Grund ist eine Verschmelzung von irgendwas=variable +
variable:reason=Grund. So eine Verschmelzung spart Schreibarbeit, ist aber
hierarchisch unsauber.

Mit highway=* ist das nur bedingt vergleichbar, denn highway=* ist ein
Maintag (top-level tag), während maxspeed:variable=* nur ein Attribut ist.

 Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist
 ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. Bitte
 dem Grundsatz we map what we see treu bleiben. Auf der A2 und der
 Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel Verkehr
 herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern...
 
 Nicht alle Gründe sondern primär der Hauptgrund. Der ist bei der
 Tangente offensichtlich peak_traffic und diese Information kann jeder
 Ortskundige (in diesem Fall - und generell bei Hauptverkehrswegen mit
 Verkehrsbeeinflussung - sehr viele) bestätigen.

Ich

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x


Wenn wir hier von Pragmatismus reden, warum wird dann die
Höchstgeschwindigkeit erfasst, die die Signalanlage erlaubt? Zugegeben,
ich fahr nicht viel Auto, aber mir fallen da durchaus Abschnitte ein, da
kommt die tatsächlich einstellbare Höchstgeschwindigkeit praktisch nie
zum Zug.


1) maxspeed ist eben als maximale (rechtliche) Höchstgeschwindigkeit 
definiert worden. Die Tatsache, dass der Wert von maxspeed in der Praxis 
nicht gefahren werden kann und für das Routing nicht immer passt, ist 
ein Problem von maxspeed selber -- und unabhängig von Signalanlagen. 
Versuche mit maxspeed:practical gibt es, so recht durchgesetzt hat es 
sich nicht (siehe letzter Absatz im Posting).


In den überwiegenden Zahl von Fällen wird die maximale 
Höchstgeschwindigkeit für das Routing aber nicht so schlecht 
funktionieren, besonders auf Autobahnen in urbanen Gegenden, wo häufig 
130 niemals erlaubt ist, sondern eher 100 oder sogar nur 80. Gerade dort 
sind auch Signalanlagen häufig. Einzelne Ausnahmen machen es trotzdem 
noch zu einer Verbesserung.


2) Die maximale erlaubte Höchstgeschwindigkeit ist kein Schätzwert und 
wird auch nicht von der Verkehrsleitzentrale frei vergeben, sondern (so 
wie alle Verkehrszeichen) gesetzlich verordnet.


- Daher gehört auch nicht der Wert hinein, der mit der Anlage technisch 
maximal möglich ist.


Jeder, der solche Abschnitte halbwegs regelmäßig fährt, kann mit fast 
absoluter Sicherheit den richtigen (verordneten) maximalen Wert nennen. 
Als Gelegenheitsmapper und Wenigfahrer sieht man das vielleicht etwas 
anders oder skeptisch, es ist aber kein praktisches Problem: Auf der 
SÖ-Tangente gilt maximal 80, da gibt es keine Zweifel von Ortskundigen - 
und es muss auch keiner eine Verordnung rauskramen. Beim 
Tradenbergtunnel gilt maximal 100, da gibt es auch keine Zweifel von 
Leuten, die dort öfters fahren.


Weiteres Beispiel: Es gilt nun auf Teilabschnitten der Inntalautobahn 
immer IGL 100, weil neuerdings so verordnet, obwohl mit der Anlage die 
Beschränkung auch aufgehoben werden könnte  -- maxspeed=100. 
Ortskundige Tiroler werden das sehr wohl wissen, ging ja auch durch die 
Medien. Die dazugehörige Verordnung 
https://www.tirol.gv.at/fileadmin/themen/umwelt/umweltrecht/LGBLA_TI_20141118_145.pdf 
musste dazu kaum jemand studieren...



Wäre es da nicht sinnvoller, wenn es die Community dafür gibt,
die das korrekt und richtig mapped, die erwartbare Geschwindigkeit zu
mappen? Was interessiert mich denn die mögliche Höchstgeschwindigkeit,
wenn die an vermutlich nichtmal an einem Drittel der Tage im Jahr
erreicht wird?


Siehe oben, meiner Meinung nach ein anderes Problem - zugegeben noch 
ohne Lösung, außer dem maxspeed:practical-Versuch.


Wenn man hier eine Chance sieht etwas anderes (praktisches) mit zu 
erfassen, weil man die Signalanlagen sowieso angreifen muss, dann kann 
man ja maxspeed:variable:typical andenken [diese Idee hat aber viel 
Konfliktpotential, denn was ist schon typisch?]. Ich sehe das aber als 
getrenntes Proposal.


Schöner wäre es, das maxspeed-Problem (Geschwindigkeit in der Praxis 
nicht erreichbar) allgemeiner in den Griff zu bekommen. Bedarf und 
willige Mapper gäbe es genug, nur will sich mittlerweile keiner mehr die 
Proposal-Voting-Hölle antun [viel Arbeit, noch mehr Nörgler, wenig 
Ehr']. Die fuzzy-Komponente lässt ja schon vorab auf heftige 
Diskussionen schließen (die Schläglöcher stören doch mein SUV 
nicht..., aber mit meiner Rickshaw..., ich fahr' nur bei Nacht und 
für mich..., mit meinem Bus..., da ist aber häufig Nebel...).


Gruß
martinq

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x


Das Alter eines Proposals oder dessen letzte Änderung sagt hingegen nix über
Akzeptanz und Verbreitung aus.


Aber es sagt was darüber aus, ob es reif für die Abstimmung ist. Ich mag es
nicht, wenn ein Proposal nur 2 Wochen lang RFC ist und dann schon abgestimmt
wird. Das ist Überrumpelungstaktik. In Fall von maxspeed:variable=* besteht
das Proposal schon lang genug, es hatte jeder genug Zeit sich an der
Diskussion zu beteiligen (auch wenn ich es nicht getan habe, Asche auf mein
Haupt). Darum gibt es keinen Grund, noch länger zuzuwarten.


+1


Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist.
maxspeed=signals allein fehlt die Information über die Maximal- bzw.
Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie
die Geschwindigkeit angezeigt wird. Die Werte von maxspeed:variable=* taugen
mir ebenfalls nicht.


Also ich sehe schon einen bedeutenden Unterschied, ob die Information über
die Maximalgeschwindigkeit in einem Tag für die Maximalgeschwindigkeit fehlt
oder ob eine nebensächliche Information, wie etwas angezeigt wird (LED,
Prismawender?) fehlt. Wenn es Interessenten für die Art der Anzeige gibt,
dann würde ich maxspeed:variable:type=led,prism,etc vorschlagen.


maxspeed=* steht eigentlich nicht für die Maximalgeschwindigkeit, sondern
für die Geschwindigkeitsbeschränkung. Wenn du in dem Tag genau das drin
haben willst, musst du eigentlich maxspeed=signals bevorzugen. maxspeed=80
ist falsch, wenn die Geschwindigkeitsbeschränkung nicht immer 80 ist.


So klar ist die Sache bezüglich Geschwindigkeitsbegrenzung nicht. Die 
einzige Referenz, die wir haben, ist (leider) das Wiki. Da wird viel 
rumgefummelt und manchmal lässt sich auch nicht mehr rekonstruieren, wie 
etwas ursprünglich gemeint war.


Trotzdem habe ich mir die Arbeit angetan:

Die aktuelle Beschreibung lautet:
The maxspeed=* tag is used to define the *maximum* legal speed limit...

Diese Formulierung sagt tatsächlich maximale 
Geschwindigkeitsbeschränkung und nicht Geschwindigkeitsbegrenzung.


Jetzt habe ich ein bisschen weiter recherchiert: Diese Formulierung 
wurde erst am 1.1.2012 eingeführt (lange vor dem Proposal, das war also 
nicht der Anlass), davor war es maximum speed that is allowed.


Das lässt durchaus auch Raum für Interpretation. Wenn mich jemand fragen 
würde: Welche Geschwindigkeit ist auf der Tangente maximal erlaubt?, 
dann sage ich 80, auch wenn manchmal 60 gilt.


Die deutsche Übersetzung ist da recht nah an dieser ursprünglichen 
Formulierung rechtlich angeordnete maximal zulässige Geschwindigkeit. 
Auch hier würde ich sagen, auf der Tangente ist 80 die 'rechtlich 
angeordnete maximal zulässige Geschwindigkeit'.


Aus meiner Sicht ist das aber irrelevant, die Frage ist doch, gibt es 
ein Problem mit der aktuellen (englischen) Definition? Wenn nein, dann 
gibt es mit maxspeed:variable auch keinen Konflikt.



Die Information, wie eine Geschwindigkeitsbeschränkung vermittelt wird, ist
vielleicht für Router nicht wichtig, für andere Anwendungen und vor allem
für die Wart- und Überprüfbarkeit der Daten sehr wohl. Darum gibt es dafür
schon länger source:maxspeed=* bzw. synonym maxspeed:type=*. Und genau da
passt nun auch der Wert signals hinein. Ob die Anzeige auf LED oder Prisma
basiert, darum geht es mir nicht, denn das ist so bedeutsam wie ob ein
Verkehrszeichen auf einer Alu- oder einer Eisenstange steht. ;-)


Dachte ich mir doch, dass ich etwas falsch verstanden habe.

Ich wollte auch schon etwas wie Was interessiert es mich, ob ein Schild 
aus Alu oder Eisen ist schreiben...


Impliziert die Verwendung von maxspeed:variable nicht bereits, dass eine 
Signalanlage vorhanden ist? Wenn es hier nicht-exotische Ausnahmen gibt 
(zB einer geht regelmäßig durch und dreht Metallschilder manuell), dann 
sollte man wirklich noch ein maxspeed:type=signals andenken.


Gruß
martinq

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

On 19.12.2014 21:31, martinq wrote:
 So klar ist die Sache bezüglich Geschwindigkeitsbegrenzung nicht. Die
 einzige Referenz, die wir haben, ist (leider) das Wiki. Da wird viel
 rumgefummelt und manchmal lässt sich auch nicht mehr rekonstruieren, wie
 etwas ursprünglich gemeint war.
 
 Trotzdem habe ich mir die Arbeit angetan:
 
 Die aktuelle Beschreibung lautet:
 The maxspeed=* tag is used to define the *maximum* legal speed limit...
 
 Diese Formulierung sagt tatsächlich maximale Geschwindigkeitsbeschränkung
 und nicht Geschwindigkeitsbegrenzung.

Ich glaube, hier ist mit maximum gemeint, dass es um die
Höchstgeschwindigkeit und nicht um die Mindestgeschwindigkeit geht. Siehe
http://wiki.openstreetmap.org/wiki/Key:minspeed:
This Key allows the specification of a minimum speed limit.

 Jetzt habe ich ein bisschen weiter recherchiert: Diese Formulierung wurde
 erst am 1.1.2012 eingeführt (lange vor dem Proposal, das war also nicht der
 Anlass), davor war es maximum speed that is allowed.

Wurde wahrscheinlich geändert, weil legal speed limit besser klingt als
speed that is allowed.
Bzw. speed that is allowed wurde von jemandem geschrieben, dem das Wort
legal nicht eingefallen ist.

Ich bin überzeugt, dass alle das gleiche meinen, nämlich die Bedeutung des
abgebildeten Verkehrszeichens. Es wurde ja nicht ein Tag erfunden und dann
überlegt, welche Verkehrszeichen dazu passen können, sondern man ging von
den Verkehrszeichen aus und hat sich dazu passende Tags ausgedacht.

 Aus meiner Sicht ist das aber irrelevant, die Frage ist doch, gibt es ein
 Problem mit der aktuellen (englischen) Definition? Wenn nein, dann gibt es
 mit maxspeed:variable auch keinen Konflikt.

Aus oben genannten Gründen sehe ich da schon ein Problem, aber man kann
natürlich alles umdefinieren, wenn dafür halbwegs ein Konsens besteht. Im
konkreten Fall beeinträchtigt eine Umdefinition keine bestehenden Daten, nur
die Anwendungen müssen so erweitert werden, dass sie das neue Tag (sei es
maxspeed:variable=* oder maxspeed:type=signals oder source:maxspeed=signals
oder was auch immer) mit auswerten.

 Impliziert die Verwendung von maxspeed:variable nicht bereits, dass eine
 Signalanlage vorhanden ist?

Wahrscheinlich ja, da im Proposal steht, dass es maxspeed=signals ersetzt.

Wenn maxspeed:variable=* eine Signalanlage impliziert, was ist dann, wenn
source:maxspeed oder maxspeed:type einen anderen Wert haben? Und was ist,
wenn dieser außerdem dem Wert von maxspeed=* widerspricht? Je mehr Tags im
Spiel sind, die miteinander zu tun haben, desto verwickelter wird das ganze.
Das ist mit ein Grund, warum ich maxspeed:variable=* skeptisch sehe. Wozu
sollen wir so was einführen, wenn ein existierendes Tag das gleiche leistet?

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

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

Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x

2014-12-19 Thread Kevin Kofler

Friedrich Volkmann wrote:
 oneway=yes war als Flag gedacht. Entweder ist es eine Einbahn oder nicht.
 Entweder ist der Tisch rund oder nicht. Aber seit man draufgekommen ist,
 dass oneway=-1 nötig werden kann, muss man sich fragen, ob ein Tag wie
 driving_direction=forward/backward/both nicht verständlicher wäre.

oneway=-1 ist grober Unfug, da sollte man einfach den Weg umdrehen (geht in 
jedem vernünftigen Editor mit 2 Klicks)!

Kevin Kofler


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

[Talk-pt] Rotas dos Transportes Urbanos de Braga

2014-12-19 Thread Miguel Borges

 Talk-pt@openstreetmap.orgOlá a todos,

Escrevo-vos para dar conta à comunidade do trabalho que estou a desenvolver
e para ver se não colide com o trabalho que algum outro membro esteja a
fazer. Ainda um apelo: se alguém quiser dar uma ajuda, é bem-vindo(a)!

Meti-me na empreitada de completar as rotas dos transportes urbanos de
Braga (TUB) com base na informação publicada no site da empresa
transportadora (www.tub.pt) e no meu conhecimento local.

A situação actual é a de 15 rotas já criadas, julgo que pelo
transportespublicospt, e que de entre as quais 3 estão com problemas de
continuidade e todas sem referência ao sentido da rota.

Das 55 rotas restantes, já criei 6, pelo que ainda restam 49.

Partilho convosco o método que estou a usar para a criação de rotas:

0. Criar relações de rotas, com prioridade às rotas que se estendam por
zonas do teritório ainda sem cobertura
1. Começo por acrescentar à relação, os segmentos no sentido da ida
2. Se o segmento é apenas percorrido na ida, marco-o com o role de
forward
3. Se o segmento é comum à ida e volta, não lhe marco role
4. Depois de acrescentar todos os segmentos ida e comuns, marco os
segmentos que apenas são feitos no regresso (incluindo partes de rotundas e
acessos) e associo-lhe o role de backward
*. Fica para uma outra fase a adição de bus_stops, pois o levantamento e
identificação não são de momento exaustivos

Uma questão sobre este tipo de trabalhos: onde acham que devo
disponibilizar info sobre evolução a das tarefas? E se alguém perceber que
estou a fazer asneira, que me avise ;)

Abraço,
Miguel Borges (mirtilo)

-- Dados particulares
Relações das rotas que estavam já criadas:
3169698, 3170247, 3170450, 3171730, 3173404, 3231617, 3299812, 3311977,
3313484, 444, 3356514, 3313604

Relações das rotas com problemas de continuidade:
3231742, 3331955, 3332367

Relações das rotas criadas por mim entretanto:
4280370, 4282032,4285307, 4285689, 4285786, 4288120
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-pt] Rotas dos Transportes Urbanos de Braga

2014-12-19 Thread Miguel Borges

Viva Gonçalo,

no site da TUB o mapa de todas as rotas está disponível em PDF. É um
trabalho que me parece razoável a transferencia da informação da rota para
o osm, sobretudo para quem conhece a geografia local. Aliás, parece-me que
qualquer outro formato de dados implicaria um processo semelhante na
importação para o osm.

Sobre o SIGGESC, que desconhecia, parece-me uma possibilidade com algum
potencial (ainda que antevendo algumas dificuldade, como ilustra este
exemplo de interação
http://www.transportespublicos.pt/carta-aberta-ao-presidente-da-area-metropolitana-do-porto/
com instituições públicas) mas cujo alcance está para lá do objectivo
inicial do meu email. Ainda assim, fica a referência.

Se vire na wiki
http://wiki.openstreetmap.org/wiki/List_of_OSM-based_services#Public_Transport
do osm há bons pontos de partida para poder planear rotas em tp com base
nas rotas do osm. Mas o ingrediente base precisa de lá estar: boas rotas e
info sobre horários - vê esta
http://mobilidade.inf.ufrgs.br/viajetrifacil/ implementação em Curitiba
do

Abraço,
Miguel Borges.

No dia 19 de dezembro de 2014 às 14:31, Gonçalo Lourenço cnog...@gmail.com
escreveu:

Viva Miguel

Já pediste essa informação aos TUB? Tenho a certeza que se quisessem, ou
pudessem, te arranjavam isso. Aliás, porque não solicitar ao regulador
(IMT) a disponibilização dos dados SIGGESC
http://www.imtt.pt/sites/IMTT/Portugues/Noticias/Paginas/UtilizacaodoSIGGESCpelosoperadoresdetransportepublicorodoviariodepassageirosDespachonormativopublicadoemDiariodaRepublica.aspx(com
o devido consentimento dos operadores) que a comunidade OSM
encarregar-se-ia de manter corretos e atualizados? É um compromisso difícil
e exigente mas iria acrescentar imenso valor ao OSM. Com as ferramentas
adequadas até podíamos ter um planeador de viagens em TP para todo o
território nacional baseado em OSM***

Abraços
Gonçalo

*** não fui verificar se já existe. Sei que o gmaps não faz ou faz apenas
para as regiões do porto e lisboa, o resto é deserto...

2014-12-19 12:44 GMT+00:00 Miguel Borges borges.mig...@gmail.com:

Talk-pt@openstreetmap.orgOlá a todos,

Escrevo-vos para dar conta à comunidade do trabalho que estou a
desenvolver e para ver se não colide com o trabalho que algum outro membro
esteja a fazer. Ainda um apelo: se alguém quiser dar uma ajuda, é
bem-vindo(a)!

Meti-me na empreitada de completar as rotas dos transportes urbanos de
Braga (TUB) com base na informação publicada no site da empresa
transportadora (www.tub.pt) e no meu conhecimento local.

A situação actual é a de 15 rotas já criadas, julgo que pelo
transportespublicospt, e que de entre as quais 3 estão com problemas de
continuidade e todas sem referência ao sentido da rota.

Das 55 rotas restantes, já criei 6, pelo que ainda restam 49.

Partilho convosco o método que estou a usar para a criação de rotas:

0. Criar relações de rotas, com prioridade às rotas que se estendam por
zonas do teritório ainda sem cobertura
1. Começo por acrescentar à relação, os segmentos no sentido da ida
2. Se o segmento é apenas percorrido na ida, marco-o com o role de
forward
3. Se o segmento é comum à ida e volta, não lhe marco role
4. Depois de acrescentar todos os segmentos ida e comuns, marco os
segmentos que apenas são feitos no regresso (incluindo partes de rotundas e
acessos) e associo-lhe o role de backward
*. Fica para uma outra fase a adição de bus_stops, pois o levantamento e
identificação não são de momento exaustivos

Uma questão sobre este tipo de trabalhos: onde acham que devo
disponibilizar info sobre evolução a das tarefas? E se alguém perceber que
estou a fazer asneira, que me avise ;)

Abraço,
Miguel Borges (mirtilo)

-- Dados particulares
Relações das rotas que estavam já criadas:
3169698, 3170247, 3170450, 3171730, 3173404, 3231617, 3299812, 3311977,
3313484, 444, 3356514, 3313604

Relações das rotas com problemas de continuidade:
3231742, 3331955, 3332367

Relações das rotas criadas por mim entretanto:
4280370, 4282032,4285307, 4285689, 4285786, 4288120

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

--
*Com os meus cumprimentos / Best regards*

*GONÇALO LOURENÇO*

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

Re: [Talk-cz] Osmose Česká republika

2014-12-19 Thread Kasparek Tomas

On Thu, Dec 18, 2014 at 05:59:20PM +0100, Marián Kyral wrote:
 Takhle jsem to dělal, když jsem opravoval špatný formát data po tracer 
 pluginu:

diky, to zni dobre, zkusim.

-- 

  Tomas Kasparek   e-mail: kaspa...@fit.vutbr.cz
  CVT FIT VUT Brno, L127   jabber: tomas.kaspa...@jabber.cz
  Bozetechova 1, 612 66web   : http://www.fit.vutbr.cz/~kasparek
  Brno, Czech Republic phone : +420 54114-1220

  GPG:2F1E 1AAF FD3B CFA3 1537  63BD DCBE 18FF A035 53BC

  May the command line live forever!


pgpsd0_TIgX3Y.pgp
Description: PGP signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Reklamace turistických tras

2014-12-19 Thread Václav Kubíček

Ahoj,
pro ty co neznají a mapují či se pohybují po turistických trasách, tak mi byl 
doporučen tento formulář KČT na hlášení chyb:
www.turistickeznaceni.cz
Nahlášený problém se předá příslučné značkařské oblasti.
 
Vašek

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

Re: [Talk-cz] Reklamace turistických tras

2014-12-19 Thread Petr Holub

Ahoj,

 pro ty co neznají a mapují či se pohybují po turistických trasách, tak mi byl 
 doporučen tento formulář
 KČT na hlášení chyb:
 www.turistickeznaceni.cz
 Nahlášený problém se předá příslučné značkařské oblasti.

a jak si v tom systemu clovek vytvori ucet (= registruje se)?

Diky,
Petr


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

Re: [OSM-talk-fr] man-made=tower avec tower:type=tower :))

2014-12-19 Thread François Lacombe

Le 18 décembre 2014 22:03, Yves Pratter yves.prat...@gmail.com a écrit :


 Je ne sais plus ce que j’ai écrit exactement, mais je pensais
 « namespace » comme dans ton exemple de référence du tranformateur.
 D’ailleurs je ne « vois » pas cette notion de hiérarchie ;-)


Pour la hiérarchie, soit l'arbre :
a:b
a:c

où b et c sont tous les deux enfants de a.

On créé facilement des catégories imbriquées les unes dans les autres avec
ce formalisme (- hiérarchie).
L'idée de grouper des clés sous-entend qu'on en met plusieurs dans le
groupe (ou qu'on prévoit de le faire).
Si il n'y en a qu'une, m'est avis qu'il faut préférer le _ pour préciser le
sens de la clé : support_type au lieu de support:type.

Est-ce qu'un support_function=anchor|termination|suspension|... sonnerait
juste ?



 En pratique tu peux mettre 2 noeuds aux même coordonnées (et ajouter ele=*
 pour l’altitude) mais c’est déconseillé car galère pour faire des
 sélections avec les éditeurs
 (même si on peut sélectionner avec JOSM 2 objets superposés en utilisant
 la touche ALT)


Oui, on va éviter :)


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

Merci Marc pour tes éclaircissements :)

 Le 19 déc. 2014 à 07:21, Marc Gemis marc.ge...@gmail.com a écrit :
 
 Yves,
 
 Since I will answer in English I write this in a private message. Feel free 
 to bring it back to the mailing list.
Je crois que tu peux même écrire en anglais sur la liste française ;-)

Je te répond en français car tu le comprends bien :)

 
 I have been following the English mailing list for a couple of months now. 
 They are some people that are against any form of mechanical edit. There has 
 been long discussions about changing the names of shops. Someone wants to 
 correct obvious spelling mistakes from the names. He has to fight some strong 
 opposition.
 See [1], [2], and [3] for the latest discussion on that topic. So it does not 
 surprise me at all that they react like this. 
 
 Furthermore, Some people do not like the medical=aed, because it is an 
 abbreviation. This discussion was held in the past year on the tagging 
 mailing list I think.
Je n’ai pas suivi les discussions, mais hier j’ai vu qu’il y avait un consensus 
sur emergency=defibrillator.
J’ai donc tenté de « finir »  le travail.

Le problème c’est que j’avais fait 2 éditions « mécaniques » (justement sur les 
amenity=shop - shop=yes) et que le radar d’un allemand (que les britanniques 
m’excusent).
Celui-ci s’est focalisé sur mes modifs.

Pas de chance pour moi, j’ai sélectionné tous les noeuds avec JOSM et un 
building=yes s’est retrouvé par erreur avec emergency=defibrillator à chaque 
coins.

 You also have to know that some of this British mappers do not like the wiki. 
 They say that the wiki and the voting mechanism is the playground of a select 
 group.
Non je ne savais pas. On n’en parle pas trop sur cette liste.

 You have to look at taginfo for what the community really thinks is their 
 mantra. Another nice statement is you have to follow the guidelines that 
 were once discussed on this mailing list »
Ok sur le principe, mais ça demande un effort important de lire/comprendre des 
discussions en anglais… et quand je vois le travail » que ça demande juste 
pour essayer de suivre la liste française :  j’hésite à m’y abonner.

 
 Anyway, for the mechanical edit policy, you have to contact each country 
 individually to see whether they will like your change or not. The contact 
 can be done via a mailing list, forum, irc.

 So IMHO, it is impossible to make any mechanical edit outside your own 
 country.
 
 I hope this helps to understand the issue a bit.
Oui, je comprends mieux les tensions qui peuvent exister au sein de LA 
communauté
.
 [1] 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016919.html 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016919.html
 [2] 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016921.html 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016921.html
 [3] 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016922.html 
 https://lists.openstreetmap.org/pipermail/talk-gb/2014-December/016922.htmlDiscussions
  intéressantes. Je n’ai pas tout compris mais les recommandations sur les 
 éditions mécaniques ne font pas l’unanimité ;-)
Et la règle qui consiste à obtenir un consensus de la communauté semble plus 
tenir en pratique de la perception métaphysique :D

Une idée me traverse : pour les vrais modifications de masse, peut-on faire un 
changement à blanc », le soumettre aux personnes qui ont éditer les objets 
touchés et attendre un délai « raisonnable » pour recevoir leur approbation/ou 
pas ?

« à blanc », ça serait en pratique faire une requête overpass par exemple, 
faire les modifications dans JOSM par exemple et sauvegarder tout ça dans un 
fichier accessible quelque part.

Un script pourrait alors envoyer automatiquement un mél aux intéressés et/ou 
aux communautés ?

—
Yves


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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

 Tes derniers edits ont une emprise mondiale. Je ne sais pas dans le détail 
 quels pays ils concernent, mais clairement ils ne sont pas localisés, du 
 coup les radars clignotent plus facilement
Oui, c’est ce qui a du se passer.

 Le type d'échange que tu as eu aujourd'hui n'est pas souvent relaté sur cette 
 liste, mais certaines fois, ça déclenche des semaines de grosse activité sur 
 plusieurs listes à la fois. Vu de chez nous, ce fil :
 https://lists.openstreetmap.org/pipermail/talk-fr/2012-September/047738.html
 a mobilisé à l'époque beaucoup d’énergie.
J’ai lu les 10 premiers pour sentir la température.

 Il a eu comme conséquence, entre autres, l'arrivée de sly[1] dans le DWG [2], 
 ce qui normalement permet, concernant les contributeurs 
 français/francophones, d'avoir des échanges plus simples. Manifestement tu as 
 eu à faire à quelqu'un d'autre cette fois-ci.
Mes interlocuteurs initiaux n’étaient pas du DWG. J’ai eu un mél de Andy 
Townsend (on behalf of the OSM data working group) mais de mémoire son « ton » 
était adapté et ses explications constructives.

La seule chose gênante à l’écouter, c’est qu’on tous les utilisateurs d’OSM 
devraient connaitre et comprendre ces recommandations. Ils n’ont probablement 
pas conscience que tous le monde ne maitrise pas l'anglais, ne connais pas 
toutes les aiguilles cachées dans la meule de foin OSM/Internet…

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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

2014-12-19 Thread Eric SIBERT


[2] : http://wiki.openstreetmap.org/wiki/FR:Data_working_group


Sans vouloir relancer le débat mais pour la culture d'Yves, je trouve 
que le DWG a dévié de ses objectifs:


gérer les accusations d' abus de droits, les importations, les 
différends graves et le vandalisme


Dans le cas d'Yves, ils auraient du:
- prendre contact, demander d'arrêter puis demander des explications (fait)
- éventuellement demander à Yves d'annuler lui-même ses modifs
- blocage si Yves ne répond pas et continue à faire des modifs

Le revert par des personnes membres ou pas du DWG est clairement un abus.

Inversement, j'ai signalé il y a un an un gars (mails à l'appui) qui 
avait utilisé GoogleMap pour contribuer. J'ai relancé deux fois. J'ai eu 
une réponse pour une demande d'informations complémentaires. Les données 
d'origine GoogleMap sont toujours dans la base OSM.


Eric


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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

2014-12-19 Thread JB


Le 19/12/2014 11:18, Yves Pratter a écrit :

La seule chose gênante à l’écouter, c’est qu’on tous les utilisateurs d’OSM 
devraient connaitre et comprendre ces recommandations. Ils n’ont probablement 
pas conscience que tous le monde ne maitrise pas l'anglais, ne connais pas 
toutes les aiguilles cachées dans la meule de foin OSM/Internet…
Mais que quand on commence à faire des corrections à grande échelle, en 
manipulant de l'Overpass ou autre, c'est qu'on commence à être impliqué 
et qu'on devrait être au courant… (on n'est plus débutant, quoi…)
Pour moi, je ne fais presque jamais de correction semi-automatique, mais 
les 2 ou 3 fois que je l'ai fait, j'ai strictement limité à la France, 
où je sais que pour les corrections d'erreurs de type frappe ou des 
conventions bien établies seront bienvenues.
Pour moi, c'est plutôt une bonne chose qu'on laisse les gens faire chez 
eux, en accord avec la communauté locale, plutôt que d'appliquer la 
rêgle du sommet (pas de bot, même à moitié humain) à tous partout. Et 
qu'on autorise les locaux à râler quand on vient mettre les pieds sur 
leurs plates-bandes avec des modifications automatiques. Vous vous 
souvenez la réaction à la suppressions des landuses chez nous (par un 
certain PN, il me semble) ?

JB.

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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

2014-12-19 Thread Nicolas Dumoulin

Bonjour,

Le jeudi 18 décembre 2014 22:29:04 Yves Pratter a écrit :
 Ouf, t’as eu chaud Nicolas :D
 Mais attention à toi, les britanniques guettent ;-)

C'est clair :-)

 Et surtout, comment discuter en pratique avec la communauté ?

J'ai fait d'autre corrections de ce genre, mais uniquement en France. Je me 
souviens des aires de décollage/atterrissage de vol libre, j'en avais parlé 
sur la liste.
Pour les aed, vu que ça a été voté et que c'est bien écrit sur le wiki, j'ai 
décidé tout seul de mettre la base en cohérence.
Je me suis limité à la France, car j'ai quand même vérifié (depuis ma chaise) 
tous les éléments que je corrigeais.

Il est clair que quand on fait ce genre d'opération, il faut faire gaffe, ne 
pas mettre un gâteau au four, et être sûr que les enfants dorment bien … bien 
relire la doc, analyser l'existant et au moindre doute contacter la liste.

Merci à Yves et à tous les correcteurs de données :-)

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs


 Le 19 déc. 2014 à 11:32, Eric SIBERT courr...@eric.sibert.fr a écrit :
 
 Dans le cas d'Yves, ils auraient du:
 - prendre contact, demander d'arrêter puis demander des explications (fait)
Le guss a fait ça. Le problème c’est qu’entre temps j’avais fait mon 2e 
changement et que lui espérait une prise ne compte de ses messages dans 
l’instant ?
Hors je n’ai pas trop utilisé ma messagerie ce jour là et surtout j’étais assez 
absorbé par la gâteau au four de Nicolas :D

 
 Le 19 déc. 2014 à 11:33, JB jb...@mailoo.org a écrit :
 
 Mais que quand on commence à faire des corrections à grande échelle, en 
 manipulant de l'Overpass ou autre, c'est qu'on commence à être impliqué et 
 qu'on devrait être au courant… (on n'est plus débutant, quoi…)
Certes, mais je ne suis pas encore dieu — je ne suis que le prochain dans la 
file :D

J’aimerais bien discuter avec le groupe OSM local dans un troquet, mais y’a pas 
de troquet dans mon village, pas plus que de groupe OSM ;-)
Les plus près sont à Lyon ou à Dijon. Rien à Besançon.

Pour info, j’ai procédé un peu comme Nicolas avec amenity=shop - supprimé pour 
les objets ayant déjà un shop=* (j’ai suivi 
http://wiki.openstreetmap.org/wiki/Key:shop#Fixme 
http://wiki.openstreetmap.org/wiki/Key:shop#Fixme)
La grosse erreur c’est d’avoir fait ça sur les objets restant sans cibler leur 
« nationalité » ;-) et aussi d’avoir corrigé dans le même changeset des 
erreurs/alertes de JOSM (pas à l’aveuglette, en analysant les messages).

Puis dans le 2e j’ai fait un amenity=shop - shop=yes.

Le changement de masse » touche 1426 objets à comparer aux 1 495 757 
shop=*(cf. http://overpass-turbo.eu/s/6Bf http://overpass-turbo.eu/s/6Bf)

 Pour moi, c'est plutôt une bonne chose qu'on laisse les gens faire chez eux, 
 en accord avec la communauté locale, plutôt que d'appliquer la rêgle du sommet
Je ne sais pas où se trouve le sommet dans ce cas : je me suis basé sur le wiki 
et — un peu —de bon sens amenity=shop fait doublon avec shop=*

 Et qu'on autorise les locaux à râler quand on vient mettre les pieds sur 
 leurs plates-bandes avec des modifications automatiques.
ça n’est pas le problème de râler, c’est le problème de la forme, d’autant plus 
que certains des modérateurs semblaient d’accord sur le fond ;-)

 Vous vous souvenez la réaction à la suppressions des landuses chez nous (par 
 un certain PN, il me semble) ?
Non, je n’étais pas né :D

—
Yves




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

Re: [OSM-talk-fr] Groupes de changements et politique de changements massifs

2014-12-19 Thread Pieren

Les mechanical edits restent possibles mais il faut prendre des
précautions. Les changements globaux sans annonces sont rarement bien
perçus. C'est plus facile si c'est fait à l'échelle de son propre pays
pour commencer.
Le problème si on ne fait rien, c'est que des doublons de tags peuvent
longtemps persister dans OSM et des actions de nettoyage doivent
parfois être entreprises. Mais pour ne pas froisser les
suceptibilités, il vaut mieux en parler avant pour expliquer la
démarche. Il ne faut pas prendre les gens par surprise, expliquer,
etc. Mais on trouvera toujours des gens qui sont contre, par principe.
Si ça résiste trop, on peut lancer une consultation publique par le
biais d'un vote ou d'un sondage en ligne pour peser les forces en
présence (la majorité silencieuse).
Pour les AED, c'est un peu ma faute aussi. Un premier vote avait
valider l'emergency=aed avec très peu de gens sur le wiki (il faut
dire que la discussion implique peu de monde). Comme je suis contre
l'usage des abbréviations dans les tags par principe, j'ai relancé un
deuxième vote avec beaucoup plus de publicité pour obtenir un autre
résultat sans abbréviation avec succès cette fois-ci (je crois que le
problème des abbréviations est largement compris ... sauf par ceux qui
les utilisent couramment ;-) mais je n'ai rien fait ensuite pour que
les données changent dans la base. Les stats étaient encore largement
en faveur de l'ancienne version jusqu'à ce que les allemands décident
d'adopter la nouvelle version (c'est chez-eux qu'il y en a le plus).
Après, c'est plus facile de convaincre les derniers récalcitrants. Les
changements ne peuvent pas / plus se faire de manière brutale à
l'échelle monde. Il faut savoir y aller progressivement.
Et ceux qui sont contre le wiki sont en fait aussi ceux qui ne veulent
pas chercher le consensus.

Pieren

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

Re: [OSM-talk-fr] man-made=tower avec tower:type=tower :))