date:20130320

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo Martin.

Am 20.03.2013 11:23, schrieb Martin Vonwald:
 Hi!
 
 Ich habe damit begonnen einzelne Verkehrsschilder zu erfassen,
 weil ich festgestellt habe, dass es oft nicht einfach ist den
 Überblick zu behalten wo jetzt ein Limit anfängt und wo es aufhört
 - vor allem wenn man Straßen nur stückerlweise mappt. Für 
 Geschwindigkeitsbeschränkungen verwende ich traffic_sign=maxspeed
 + maxspeed=x . Soweit so klar, nur das erste Problem wartete nicht 
 lange: wie mappe ich das Ende der Beschränkung? Nach einigem hin
 und her entschloss ich mich zu maxspeed=implicit, da so ein Schild
 ja eigentlich genau das aussagt: aber hier gilt die allgemeine,
 implizite Geschwindigkeitsbegrenzung.

Ich sehe das Problem schon früher: Was heißt denn für dich Anfang
und Ende?
Im Normalfall steht das Verkehrsschild, das du mappst, ja nicht an
einer Einbahnstraße, sondern an einer, die zwei Richtungen kennt. Wenn
Du das Schild neben der Straße einträgst, braucht man für die Auswertung
1) die Geometrie: okay, das Schild steht nahe von Straße X
2) die Richtung, in der das Schild jetzt gelten soll. An der
Straßenseite kann man das nicht zwingend ausmachen, denn manchmal sind
Verkehrsschilder auch beidseitig angebracht. Abgesehen davon ist das
Wissen über das lokale Verkehrssystem (Linksverkehr, Rechtsverkehr)
notwendig.

Mappst Du das Schild als node der Straße, dann fällt 1 als
Schwierigkeit weg, 2 bleibt aber.

Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen eben
üblicherweise vor allem am way getagged, und nicht als Schilder.
Ob es übersichtlicher wird, wenn die Schilder eingetragen sind,
bezweifle ich, denn das sind erstmal nur zusätzliche nodes im editor.

Nichtsdestotrotz würde ich die Schilder aber evtl. auch eintragen.

 
 Bei Überholverboten habe ich jetzt ein ähnliches Problem. Der
 Beginn ist klar: traffic_sign=overtaking + overtaking=no. Aber wie
 das Ende? Passt hier ein overtaking=yes (das steht nicht am
 Schild)? Oder vielleicht auch besser ein implicit hier?
siehe oben: ich würds als Eigenschaft des Weges eintragen.
 
 Bevor ihr antwortet bitte berücksichtigt, dass ich ausschließlich
 von Verkehrsschildern rede. Ich möchte jetzt bitte keine x-te
 Diskussion lostreten ob Geschwindigkeitslimits auf den Straßen so
 oder so oder ganz anders zu mappen sind ;-)
hmm... sorry, aber das hättest du vorher schreiben müssen.. ;)
Aber:
 Und für mich sind die Verkehrsschilder in erste Linie auch nur
 eine Erleichterung zum Mappen. Mich nervten die hunderten Knoten
 mit note=Beginn 70 und note=Ende Überholverbot.
das verstehe ich, und note ist auch sicher NICHT auswertbar.
Aber maxspeed am Weg ist auswertbar, und overtaking=no (oder
ähnliches, ich hab keine Ahnung, wie das eingetragen wird) ist es auch.
Ich will das ganze auch
 während des Editierens sehen und dazu muss es auswertbar sein, was 
 eine note nicht ist.
Dazu müsste es doch machbar sein, 'nen Stil zu schreiben, der entweder
die Schilder als icons auf dem way anzeigt oder den weg entsprechend
umfärbt etc.

Ich jedenfalls würde den Weg gehen, bevor Hilfskonstruktionen aus
zusätzlichen Nodes herangezogen werden, die die Übersichtlichkeit für
den Mapper nur scheinbar verbessern, denn wenn deine Hilfsnodes den
Way-Attributen widersprechen, hast du gar nichts gewonnen.

Gruß
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFJlaQACgkQi8ffXNvWmYQwAgCfayEWwNSSbUqZVeOn47D6oyUV
yecAn2T+cB9qNKuSPMFrn/wagIbQjbri
=4lvg
-END PGP SIGNATURE-

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

2013-03-20 Thread Martin Vonwald

Hi!

Hm... ok, alle meine Mails starten in Zukunft mit: Bitte zuerst
vollständig lesen und erst danach antworten ;-)

Natürlich sollen die Geschwindigkeiten auf die Wege. Die
Verkehrsschilder sind nur als Hilfe für die Mapper gedacht. Sehr oft
hat man gerade rund um Kreuzungen unterschiedliche Geschwindigkeiten
pro Fahrtrichtung und wenn man dann nur eine Richtung abfährt und die
Geschwindigkeiten entsprechend einträgt sind die Werte für die andere
Richtung entweder falsch oder fehlen komplett.
Wenn man die Schilder zusätzlich einträgt kann man das ganze
stückweise machen. Widersprüche kann es natürlich immer geben - das
ist dann ein Hinweis den Status neu zu ermitteln.

So stelle ich mir das vor:
http://www.vonwald.info/osm/images/Speedlimit%20Trafficsign.jpeg

Mir geht es nur darum die note-Knoten zu ersetzen durch etwas was
sinnvoll auswertbar ist.

vg,
Martin


Am 20. März 2013 11:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hallo Martin.

 Am 20.03.2013 11:23, schrieb Martin Vonwald:
 Hi!

 Ich habe damit begonnen einzelne Verkehrsschilder zu erfassen,
 weil ich festgestellt habe, dass es oft nicht einfach ist den
 Überblick zu behalten wo jetzt ein Limit anfängt und wo es aufhört
 - vor allem wenn man Straßen nur stückerlweise mappt. Für
 Geschwindigkeitsbeschränkungen verwende ich traffic_sign=maxspeed
 + maxspeed=x . Soweit so klar, nur das erste Problem wartete nicht
 lange: wie mappe ich das Ende der Beschränkung? Nach einigem hin
 und her entschloss ich mich zu maxspeed=implicit, da so ein Schild
 ja eigentlich genau das aussagt: aber hier gilt die allgemeine,
 implizite Geschwindigkeitsbegrenzung.

 Ich sehe das Problem schon früher: Was heißt denn für dich Anfang
 und Ende?
 Im Normalfall steht das Verkehrsschild, das du mappst, ja nicht an
 einer Einbahnstraße, sondern an einer, die zwei Richtungen kennt. Wenn
 Du das Schild neben der Straße einträgst, braucht man für die Auswertung
 1) die Geometrie: okay, das Schild steht nahe von Straße X
 2) die Richtung, in der das Schild jetzt gelten soll. An der
 Straßenseite kann man das nicht zwingend ausmachen, denn manchmal sind
 Verkehrsschilder auch beidseitig angebracht. Abgesehen davon ist das
 Wissen über das lokale Verkehrssystem (Linksverkehr, Rechtsverkehr)
 notwendig.

 Mappst Du das Schild als node der Straße, dann fällt 1 als
 Schwierigkeit weg, 2 bleibt aber.

 Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen eben
 üblicherweise vor allem am way getagged, und nicht als Schilder.
 Ob es übersichtlicher wird, wenn die Schilder eingetragen sind,
 bezweifle ich, denn das sind erstmal nur zusätzliche nodes im editor.

 Nichtsdestotrotz würde ich die Schilder aber evtl. auch eintragen.


 Bei Überholverboten habe ich jetzt ein ähnliches Problem. Der
 Beginn ist klar: traffic_sign=overtaking + overtaking=no. Aber wie
 das Ende? Passt hier ein overtaking=yes (das steht nicht am
 Schild)? Oder vielleicht auch besser ein implicit hier?
 siehe oben: ich würds als Eigenschaft des Weges eintragen.

 Bevor ihr antwortet bitte berücksichtigt, dass ich ausschließlich
 von Verkehrsschildern rede. Ich möchte jetzt bitte keine x-te
 Diskussion lostreten ob Geschwindigkeitslimits auf den Straßen so
 oder so oder ganz anders zu mappen sind ;-)
 hmm... sorry, aber das hättest du vorher schreiben müssen.. ;)
 Aber:
 Und für mich sind die Verkehrsschilder in erste Linie auch nur
 eine Erleichterung zum Mappen. Mich nervten die hunderten Knoten
 mit note=Beginn 70 und note=Ende Überholverbot.
 das verstehe ich, und note ist auch sicher NICHT auswertbar.
 Aber maxspeed am Weg ist auswertbar, und overtaking=no (oder
 ähnliches, ich hab keine Ahnung, wie das eingetragen wird) ist es auch.
 Ich will das ganze auch
 während des Editierens sehen und dazu muss es auswertbar sein, was
 eine note nicht ist.
 Dazu müsste es doch machbar sein, 'nen Stil zu schreiben, der entweder
 die Schilder als icons auf dem way anzeigt oder den weg entsprechend
 umfärbt etc.

 Ich jedenfalls würde den Weg gehen, bevor Hilfskonstruktionen aus
 zusätzlichen Nodes herangezogen werden, die die Übersichtlichkeit für
 den Mapper nur scheinbar verbessern, denn wenn deine Hilfsnodes den
 Way-Attributen widersprechen, hast du gar nichts gewonnen.

 Gruß
 Peter
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlFJlaQACgkQi8ffXNvWmYQwAgCfayEWwNSSbUqZVeOn47D6oyUV
 yecAn2T+cB9qNKuSPMFrn/wagIbQjbri
 =4lvg
 -END PGP SIGNATURE-

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

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

2013-03-20 Thread Walter Nordmann

Martin Vonwald (Imagic) wrote
 Mir geht es nur darum die note-Knoten zu ersetzen durch etwas was
 sinnvoll auswertbar ist.

Uns auch:

Werte bitte die Information aus, trage sie korrekt - und damit für Programme
auswertbar - in OSM als Eigenschaft des Weges ein und lösche die Note
danach.

Gruß
walter 




--
View this message in context: 
http://gis.19327.n5.nabble.com/Verkehrsschilder-Ende-von-Geschwindigkeitslimit-Uberholverbot-usw-tp5753980p5754002.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

2013-03-20 Thread Ronny Soak

Ich mappe auch ab und an Verkehsschilder. Zum Beispiel sammele ich 
gerade Umweltzoneneinfahrtsverbotsschilder, um dann irgendwann mal eine 
Grenze eintragen zu können.


Ein Problem, die richtigen Tags zu finden habe ich dabei nicht.
Mit traffic_sign=DE: und der amtlichen Nummer des Schildes (siehe 
Wikipedia) kannst du jedes (offizielle) deutsche Verkehrszeichen mappen.


Ob ich am Ende die Nodes wieder entferne, weiss ich noch nicht.
Mindestens so wichtig wie Gullideckel sind Verkehrszeichen ja wohl auch, 
also warum nicht drin lassen?


Das Problem der Übersichtlichkeit im Editor kann man eh nicht ewig vor 
sich her schieben.
Die Detaildichte wird immer weiter zunehmen, irgendwann geht es nunmal 
nicht ohne Filter.
Mich stören die Stromleitungen auch beim editieren, aber ich würde sie 
deswegen nicht aus OSM entfernen wollen, nur weil man nicht auf ihnen 
laufen/fahren kann.



Gruss,

Chaos

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 11:23 schrieb Martin Vonwald imagic@gmail.com:
 Ich habe damit begonnen einzelne Verkehrsschilder zu erfassen, weil
 ich festgestellt habe, dass es oft nicht einfach ist den Überblick zu
 behalten wo jetzt ein Limit anfängt und wo es aufhört - vor allem wenn
 man Straßen nur stückerlweise mappt. Für
 Geschwindigkeitsbeschränkungen verwende ich traffic_sign=maxspeed +
 maxspeed=x .


Freut mich, dieses Schema nutze ich auch. Falls Du es noch nicht
gefunden haben solltest, es gibt auch einen JOSM mappaint style der
diese Verkehrsschilder anzeigt (mit richtigen Zahlen im Kreis).
maxspeedsigns oder so ähnlich


 Soweit so klar, nur das erste Problem wartete nicht
 lange: wie mappe ich das Ende der Beschränkung? Nach einigem hin und
 her entschloss ich mich zu maxspeed=implicit, da so ein Schild ja
 eigentlich genau das aussagt: aber hier gilt die allgemeine, implizite
 Geschwindigkeitsbegrenzung.


bisher nutze ich maxspeed=default für die Schilder, die das Ende des
Limits anzeigen (unabhängig davon, ob das jetzt eine durchgestrichene
Zahl ist, oder ein generisches Schild das alle Streckenverbote
aufhebt). Zusammen mit dem maxspeed und dem source:maxspeed auf dem
way ergibt sich, welches implizite Limit dann gilt.


 Und für mich sind die Verkehrsschilder in erste Linie auch nur eine
 Erleichterung zum Mappen. Mich nervten die hunderten Knoten mit
 note=Beginn 70 und note=Ende Überholverbot. Ich will das ganze auch
 während des Editierens sehen und dazu muss es auswertbar sein, was
 eine note nicht ist.


+1, die Knoten der Verkehrsschilder setze ich auch nicht auf den way
sondern rechts daneben.

Gruß Martin

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Martin.

Und so hatte ich das gemeint:
http://jugglingsource.de/osm/trafficSignStyle.png

Umgesetzt als Stil für JOSM kann man den problemlos aktivieren, wenn
man maxspeed mapped.

Die Darstellung ist dabei analog z.B. zu Highway-Shields oder
oneway-Pfeilen, das sollte also gar kein Problem sein.
Wenn man die Analogie zu den Shields umsetzen kann, sollte sogar der
Wert des Tags darin übernehmbar sein.

Während deine Variante immer noch
1) Inkonsistenzen fördert, ja, sogar versteckt (denn nicht jeder
träägt die hilfsnodes nur temporär ein),
2) Fehlende Werte immer noch nicht eindeutig zeigt (sondern nur dann,
wenn der hilfsnode da ist; und dann auch nicht passend zum Tag auf dem
Weg),
3) erfordert, dass man im Rechtsverkehr denkt (bzw. im Linksverkehr,
wenn du über die NOdes eines englischen Mappers stolperst), um nicht
gerade im Beispielfall maxspeed zwischen der unteren Linken Ecke und
kurz-hinter-der-Kreuzung zu sehen,

...sind mit dem Pattern wie von mir jetzt mal nur mit Inkscape
reingemalt die genannten Probleme hinfällig.

Für Überholverbote etc. gilt das analog; für Richtungsabhängige Ge-
oder Verbote müsste man entsprechend noch 'nen Pfeil einbauen, aber
auch das wäre nicht weiter problematisch.

Gruß
Peter

Am 20.03.2013 12:50, schrieb Martin Vonwald:
 Hi!
 
 Hm... ok, alle meine Mails starten in Zukunft mit: Bitte zuerst 
 vollständig lesen und erst danach antworten ;-)
 
 Natürlich sollen die Geschwindigkeiten auf die Wege. Die 
 Verkehrsschilder sind nur als Hilfe für die Mapper gedacht. Sehr
 oft hat man gerade rund um Kreuzungen unterschiedliche
 Geschwindigkeiten pro Fahrtrichtung und wenn man dann nur eine
 Richtung abfährt und die Geschwindigkeiten entsprechend einträgt
 sind die Werte für die andere Richtung entweder falsch oder fehlen
 komplett. Wenn man die Schilder zusätzlich einträgt kann man das
 ganze stückweise machen. Widersprüche kann es natürlich immer geben
 - das ist dann ein Hinweis den Status neu zu ermitteln.
 
 So stelle ich mir das vor: 
 http://www.vonwald.info/osm/images/Speedlimit%20Trafficsign.jpeg
 
 Mir geht es nur darum die note-Knoten zu ersetzen durch etwas was 
 sinnvoll auswertbar ist.
 
 vg, Martin
 
 
 Am 20. März 2013 11:55 schrieb Peter Wendorff
 wendo...@uni-paderborn.de: Hallo Martin.
 
 Am 20.03.2013 11:23, schrieb Martin Vonwald:
 Hi!
 
 Ich habe damit begonnen einzelne Verkehrsschilder zu
 erfassen, weil ich festgestellt habe, dass es oft nicht
 einfach ist den Überblick zu behalten wo jetzt ein Limit
 anfängt und wo es aufhört - vor allem wenn man Straßen nur
 stückerlweise mappt. Für Geschwindigkeitsbeschränkungen
 verwende ich traffic_sign=maxspeed + maxspeed=x . Soweit so
 klar, nur das erste Problem wartete nicht lange: wie mappe
 ich das Ende der Beschränkung? Nach einigem hin und her
 entschloss ich mich zu maxspeed=implicit, da so ein Schild ja
 eigentlich genau das aussagt: aber hier gilt die allgemeine, 
 implizite Geschwindigkeitsbegrenzung.
 
 Ich sehe das Problem schon früher: Was heißt denn für dich
 Anfang und Ende? Im Normalfall steht das Verkehrsschild, das du
 mappst, ja nicht an einer Einbahnstraße, sondern an einer, die zwei
 Richtungen kennt. Wenn Du das Schild neben der Straße einträgst,
 braucht man für die Auswertung 1) die Geometrie: okay, das Schild
 steht nahe von Straße X 2) die Richtung, in der das Schild jetzt
 gelten soll. An der Straßenseite kann man das nicht zwingend
 ausmachen, denn manchmal sind Verkehrsschilder auch beidseitig
 angebracht. Abgesehen davon ist das Wissen über das lokale
 Verkehrssystem (Linksverkehr, Rechtsverkehr) notwendig.
 
 Mappst Du das Schild als node der Straße, dann fällt 1 als 
 Schwierigkeit weg, 2 bleibt aber.
 
 Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen
 eben üblicherweise vor allem am way getagged, und nicht als
 Schilder. Ob es übersichtlicher wird, wenn die Schilder eingetragen
 sind, bezweifle ich, denn das sind erstmal nur zusätzliche nodes im
 editor.
 
 Nichtsdestotrotz würde ich die Schilder aber evtl. auch eintragen.
 
 
 Bei Überholverboten habe ich jetzt ein ähnliches Problem.
 Der Beginn ist klar: traffic_sign=overtaking + overtaking=no.
 Aber wie das Ende? Passt hier ein overtaking=yes (das steht
 nicht am Schild)? Oder vielleicht auch besser ein implicit
 hier?
 siehe oben: ich würds als Eigenschaft des Weges eintragen.
 
 Bevor ihr antwortet bitte berücksichtigt, dass ich
 ausschließlich von Verkehrsschildern rede. Ich möchte jetzt
 bitte keine x-te Diskussion lostreten ob
 Geschwindigkeitslimits auf den Straßen so oder so oder ganz
 anders zu mappen sind ;-)
 hmm... sorry, aber das hättest du vorher schreiben müssen.. ;) 
 Aber:
 Und für mich sind die Verkehrsschilder in erste Linie auch
 nur eine Erleichterung zum Mappen. Mich nervten die hunderten
 Knoten mit note=Beginn 70 und note=Ende Überholverbot.
 das verstehe ich, und note ist auch sicher NICHT auswertbar. Aber
 maxspeed am Weg ist

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 11:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Ich sehe das Problem schon früher: Was heißt denn für dich Anfang
 und Ende?


ich mappe alle Schilder, auch Wiederholungen, sozusagen als
Bestätigung. Das ist ja gerade der Clue, auch wenn man nicht die
komplette Straße begangen ist, kann man schonmal das, was man gesehen
hat, eintragen. Zusammen mit anderen Mappern entsteht so nach und nach
ein komplettes Bild.


 Im Normalfall steht das Verkehrsschild, das du mappst, ja nicht an
 einer Einbahnstraße, sondern an einer, die zwei Richtungen kennt. Wenn
 Du das Schild neben der Straße einträgst, braucht man für die Auswertung
 1) die Geometrie: okay, das Schild steht nahe von Straße X
 2) die Richtung, in der das Schild jetzt gelten soll. An der
 Straßenseite kann man das nicht zwingend ausmachen, denn manchmal sind
 Verkehrsschilder auch beidseitig angebracht. Abgesehen davon ist das
 Wissen über das lokale Verkehrssystem (Linksverkehr, Rechtsverkehr)
 notwendig.


ja, dieses Wissen (Rechtsverkehr) ist notwendig, aber das sehe ich als
gegeben an, da man maxspeed ja sowieso nur mit Ortskenntnis mappen
kann. Was beidseitige (oder über der Fahrbahn angebrachte) Schilder
angeht: ich idealisiere das ein bisschen ;-) Ist ja wie gesagt vor
allem ein Hinweis für andere Mapper, und dient vorrangig der (viel
wichtigeren) Kontrolle der maxspeed-Werte auf dem highway.


 Mappst Du das Schild als node der Straße, dann fällt 1 als
 Schwierigkeit weg, 2 bleibt aber.


ja, daher wie gesagt neben der Straße.


 Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen eben
 üblicherweise vor allem am way getagged, und nicht als Schilder.


das soll ja auch so bleiben, die Schilder sind ein zusätzlicher Hinweis


 Ob es übersichtlicher wird, wenn die Schilder eingetragen sind,
 bezweifle ich, denn das sind erstmal nur zusätzliche nodes im editor.


aus meiner Erfahrung in den letzten Jahren kann ich nur sagen, dass
das eine riesige Hilfe ist, um so mehr, wenn die Verkehrsschilder
nicht sonderlich konsistent sind (z.B. 50, nur wenige Meter 90 default
dann 70 oder so).


 Ich jedenfalls würde den Weg gehen, bevor Hilfskonstruktionen aus
 zusätzlichen Nodes herangezogen werden, die die Übersichtlichkeit für
 den Mapper nur scheinbar verbessern, denn wenn deine Hilfsnodes den
 Way-Attributen widersprechen, hast du gar nichts gewonnen.


doch, m.E. sind die Schilder bei Widersprüchen verlässlicher, da ways
oft lang sind und der Mapper ggf. nicht die komplette Länge überprüft
hat. Im Zweifel kann man natürlich auch nochmal hinfahren, zumindest
hat man dann einen Anhaltspunkt auf mögliche Fehlerstellen.

Gruß Martin

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 13:24 schrieb Ronny Soak chaoschaos0...@googlemail.com:
 Ob ich am Ende die Nodes wieder entferne, weiss ich noch nicht.
 Mindestens so wichtig wie Gullideckel sind Verkehrszeichen ja wohl auch,
 also warum nicht drin lassen?


+1, diese Infos sind nicht nur zur Ersterfassung sondern mindestens
genauso auch zur Datenpflege und Überprüfung relevant. Das danach zu
löschen halte ich für Vandalismus, das Schild gibt es ja dort.

Gruß Martin

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 13:37 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Und so hatte ich das gemeint:
 http://jugglingsource.de/osm/trafficSignStyle.png

 Umgesetzt als Stil für JOSM kann man den problemlos aktivieren, wenn
 man maxspeed mapped.

 Die Darstellung ist dabei analog z.B. zu Highway-Shields oder
 oneway-Pfeilen, das sollte also gar kein Problem sein.
 Wenn man die Analogie zu den Shields umsetzen kann, sollte sogar der
 Wert des Tags darin übernehmbar sein.

 Während deine Variante immer noch
 1) Inkonsistenzen fördert, ja, sogar versteckt (denn nicht jeder
 träägt die hilfsnodes nur temporär ein),
 2) Fehlende Werte immer noch nicht eindeutig zeigt (sondern nur dann,
 wenn der hilfsnode da ist; und dann auch nicht passend zum Tag auf dem
 Weg),
 3) erfordert, dass man im Rechtsverkehr denkt (bzw. im Linksverkehr,
 wenn du über die NOdes eines englischen Mappers stolperst), um nicht
 gerade im Beispielfall maxspeed zwischen der unteren Linken Ecke und
 kurz-hinter-der-Kreuzung zu sehen,

 ...sind mit dem Pattern wie von mir jetzt mal nur mit Inkscape
 reingemalt die genannten Probleme hinfällig.


dafür hat man wieder das Problem, dass man die Positionen aller
Schilder auswendig kennen muss, um die Richtigkeit zu überprüfen ;-)

Gruß Martin

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20.03.2013 13:54, schrieb Martin Koppenhoefer:
 
 dafür hat man wieder das Problem, dass man die Positionen aller 
 Schilder auswendig kennen muss, um die Richtigkeit zu überprüfen
 ;-)
Klar, aber das muss ich auch, wenn da ein paar Schilder in der
Datenbank vorhanden sind, solange ich mir nicht sicher sein kann, dass
die dann vollständig sind.

Verifizieren von OSM-Daten auf Grundlage anderer OSM-Daten, die nicht
besser verifiziert sind (und dass die schilder-nodes besser
verifiziert sind im Allgemeinen, wage ich mal zu bezweifeln) hilft nichts.

Bestenfalls kriegt man daraus die Info, dass es inkonsistent ist,
schlimmstenfalls gaukelt ein doppelter Fehler vor, es sei konsistent
und deshalb vermutlich richtig.

Um die Richtigkeit zu überprüfen brauche ich gerade bei
maxspeed-Angaben grundsätzlich das lokale Wissen oder eine andere
Quelle von außen.

Selbst wenn die Schilder als redundante Information wirklich eine
Hilfe wären, ist das aber kein Grund, nicht insbesondere und vorrangig
die Visualisierung der entsprechenden way-Attribute zu forcieren, denn
dein Verifikationsargument stimmt ja nur dann, wenn auch die sichtbar
sind; und wenn die unsichtbar sind, gibt es auch keinen großen
Vorteil, die Nodes sichtbar zu machen.

Gruß
Peter

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20.03.2013 13:49, schrieb Martin Koppenhoefer:
 Am 20. März 2013 11:55 schrieb Peter Wendorff
 wendo...@uni-paderborn.de:
 Ich sehe das Problem schon früher: Was heißt denn für dich
 Anfang und Ende?
 
 
 ich mappe alle Schilder, auch Wiederholungen, sozusagen als 
 Bestätigung. Das ist ja gerade der Clue, auch wenn man nicht die 
 komplette Straße begangen ist, kann man schonmal das, was man
 gesehen hat, eintragen. Zusammen mit anderen Mappern entsteht so
 nach und nach ein komplettes Bild.
richtig, das mache ich üblicherweise über ein Fixme-Tag fixme: ab
hier Richtung Bielefeld ist Tempo 70, ich weiß aber nicht, bis wohin,
oder ich trage sogar den überschaubaren Abschnitt schonmal ein (100
Meter kann man meist überblicken, um zu sehen, dass bis dahin kein
Tempolimit aufgehoben oder verändert wird), und packe da das fixme mit
dran (fixme: Richtung Bielefeld maxspeed nicht beendet).
Warum das jetzt mit Nodes und spezialtags passieren müsste, versteh
ich in diesem Spezialfall nicht, zumal das Taggingschema der
Verkehrsschilder alleine ja noch nicht auf Unvollständigkeit oder
Fehler schließen lässt.
 
 
 Im Normalfall steht das Verkehrsschild, das du mappst, ja nicht
 an einer Einbahnstraße, sondern an einer, die zwei Richtungen
 kennt. Wenn Du das Schild neben der Straße einträgst, braucht man
 für die Auswertung 1) die Geometrie: okay, das Schild steht nahe
 von Straße X 2) die Richtung, in der das Schild jetzt gelten
 soll. An der Straßenseite kann man das nicht zwingend ausmachen,
 denn manchmal sind Verkehrsschilder auch beidseitig angebracht.
 Abgesehen davon ist das Wissen über das lokale Verkehrssystem
 (Linksverkehr, Rechtsverkehr) notwendig.
 
 ja, dieses Wissen (Rechtsverkehr) ist notwendig, aber das sehe
 ich als
 gegeben an, da man maxspeed ja sowieso nur mit Ortskenntnis mappen 
 kann. Was beidseitige (oder über der Fahrbahn angebrachte)
 Schilder angeht: ich idealisiere das ein bisschen ;-) Ist ja wie
 gesagt vor allem ein Hinweis für andere Mapper, und dient vorrangig
 der (viel wichtigeren) Kontrolle der maxspeed-Werte auf dem
 highway.
Falsch.
Ein Verkehrszeichen ist ein Verkehrszeichen ist ein Verkehrszeichen.
Ein Verkehrszeichen, das eine Höchstgeschwindigkeit angibt, würde ich
in einem Blindenrouter mit Fug und Recht erstmal auch als Hindernis
sehen, wenn ich auswerten kann, dass es wohl auf dem Bürgersteig
steht, und entsprechend davor warnen.

Eine Information über die Höchstgeschwindigkeit kann man gerne
idealisieren, aber bitte kein Verkehrszeichen, das ist neben seiner
Bedeutung nämlich bitte schön auch ein materiell vorhandener
Gegenstand: Man kann dagegenlaufen, Girlanden oder Flyer dran
aufhängen und so weiter.
Du idealisierst ja auch keine Straßenlaternen, indem du
highway=street_lamp an Nodes neben der Straße irgendwohin klebst,
sondern du pappst lit=yes an den way, und das ist gut und richtig so.

VerkehrsZEICHEN an Stellen, wo die nicht stehen, sind schlichtweg
Fehler, denn die existieren da nicht.

 Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen
 eben üblicherweise vor allem am way getagged, und nicht als
 Schilder.
 
 
 das soll ja auch so bleiben, die Schilder sind ein zusätzlicher
 Hinweis
aber für Autofahrer, nicht für Mapper.
 
 
 Ob es übersichtlicher wird, wenn die Schilder eingetragen sind, 
 bezweifle ich, denn das sind erstmal nur zusätzliche nodes im
 editor.
 
 aus meiner Erfahrung in den letzten Jahren kann ich nur sagen,
 dass
 das eine riesige Hilfe ist, um so mehr, wenn die Verkehrsschilder 
 nicht sonderlich konsistent sind (z.B. 50, nur wenige Meter 90
 default dann 70 oder so).
icons auf dem way sind hier aber immer noch kein Problem, und
zumindest josm erlaubt mittlerweile komfortabel das (de)aktivieren von
solchen overlay-Stilen im Menü.
 
 
 Ich jedenfalls würde den Weg gehen, bevor Hilfskonstruktionen
 aus zusätzlichen Nodes herangezogen werden, die die
 Übersichtlichkeit für den Mapper nur scheinbar verbessern, denn
 wenn deine Hilfsnodes den Way-Attributen widersprechen, hast du
 gar nichts gewonnen.
 
 
 doch, m.E. sind die Schilder bei Widersprüchen verlässlicher, da
 ways oft lang sind und der Mapper ggf. nicht die komplette Länge
 überprüft hat. Im Zweifel kann man natürlich auch nochmal
 hinfahren, zumindest hat man dann einen Anhaltspunkt auf mögliche
 Fehlerstellen.
wenn jemand nochmal hinfahren muss, gehört da ein fixme dran, DAS ist
der Anhaltspunkt für mögliche bzw. sogar bekannte Fehlerstellen
schlechthin.


Gruß
Peter

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 14:20 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 20.03.2013 13:54, schrieb Martin Koppenhoefer:

 dafür hat man wieder das Problem, dass man die Positionen aller
 Schilder auswendig kennen muss, um die Richtigkeit zu überprüfen
 ;-)
 Klar, aber das muss ich auch, wenn da ein paar Schilder in der
 Datenbank vorhanden sind, solange ich mir nicht sicher sein kann, dass
 die dann vollständig sind.


sehe ich nicht so, ich gehe erstmal davon aus, dass sie vollständig
sind, und wenn ich dann zusätzliche noch nicht gemappte Schilder
finde, mappe ich die und deren Auswirkungen halt bei Entdeckung.


 Verifizieren von OSM-Daten auf Grundlage anderer OSM-Daten, die nicht
 besser verifiziert sind (und dass die schilder-nodes besser
 verifiziert sind im Allgemeinen, wage ich mal zu bezweifeln) hilft nichts.


kommt sicher auf die Gegend an, auf die Anzahl der Mapper, auf die
Anzahl der erfahrenen Mapper etc., in meinem Umfeld sind die
Schild-Positionen quasi immer richtig, maxspeed Angaben auf dem way
dagegen sehr oft geraten oder ziemlich ungenau.


 Bestenfalls kriegt man daraus die Info, dass es inkonsistent ist,
 schlimmstenfalls gaukelt ein doppelter Fehler vor, es sei konsistent
 und deshalb vermutlich richtig.


das kann ja immer vorkommen, irgendwann merkt es dann trotzdem jemand,
und korrigiert es.


 Um die Richtigkeit zu überprüfen brauche ich gerade bei
 maxspeed-Angaben grundsätzlich das lokale Wissen oder eine andere
 Quelle von außen.


m.E. sollten wir nur auf das lokale Wissen setzen, die externen
Quellen haben auch Fehler, und sind nicht grundsätzlich verlässlicher,
aktueller etc.. Ground-truth eben.


 Selbst wenn die Schilder als redundante Information wirklich eine
 Hilfe wären, ist das aber kein Grund, nicht insbesondere und vorrangig
 die Visualisierung der entsprechenden way-Attribute zu forcieren, denn
 dein Verifikationsargument stimmt ja nur dann, wenn auch die sichtbar
 sind; und wenn die unsichtbar sind, gibt es auch keinen großen
 Vorteil, die Nodes sichtbar zu machen.


ja, unbestritten, es gibt ja auch schon einen anderen Stil für JOSM,
der genau das anzeigt.

Gruß Martin

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

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20. März 2013 14:31 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 ich mappe alle Schilder, auch Wiederholungen, sozusagen als
 Bestätigung. Das ist ja gerade der Clue, auch wenn man nicht die
 komplette Straße begangen ist, kann man schonmal das, was man
 gesehen hat, eintragen. Zusammen mit anderen Mappern entsteht so
 nach und nach ein komplettes Bild.
 richtig, das mache ich üblicherweise über ein Fixme-Tag fixme: ab
 hier Richtung Bielefeld ist Tempo 70, ich weiß aber nicht, bis wohin,
 oder ich trage sogar den überschaubaren Abschnitt schonmal ein (100
 Meter kann man meist überblicken, um zu sehen, dass bis dahin kein
 Tempolimit aufgehoben oder verändert wird), und packe da das fixme mit
 dran (fixme: Richtung Bielefeld maxspeed nicht beendet).


was macht dann der nächste Mapper draus, der den way (aus anderem
Grund) splittet aber nicht auf die Geschwindigkeitsbegrenzung geachtet
hat? An welchem way lässt er das fixme, oder löscht der das dann
komplett?


 Warum das jetzt mit Nodes und spezialtags passieren müsste, versteh
 ich in diesem Spezialfall nicht, zumal das Taggingschema der
 Verkehrsschilder alleine ja noch nicht auf Unvollständigkeit oder
 Fehler schließen lässt.


was meinst Du mit Spezialtags? Ich tagge das mit traffic_sign=maxspeed
 und maxspeed=x


 gegeben an, da man maxspeed ja sowieso nur mit Ortskenntnis mappen
 kann. Was beidseitige (oder über der Fahrbahn angebrachte)
 Schilder angeht: ich idealisiere das ein bisschen ;-) Ist ja wie
 gesagt vor allem ein Hinweis für andere Mapper, und dient vorrangig
 der (viel wichtigeren) Kontrolle der maxspeed-Werte auf dem
 highway.
 Falsch.
 Ein Verkehrszeichen ist ein Verkehrszeichen ist ein Verkehrszeichen.


OK, da stand ein bisschen.


 Ein Verkehrszeichen, das eine Höchstgeschwindigkeit angibt, würde ich
 in einem Blindenrouter mit Fug und Recht erstmal auch als Hindernis
 sehen, wenn ich auswerten kann, dass es wohl auf dem Bürgersteig
 steht, und entsprechend davor warnen.


wieso das denn nun? Ein Verkehrszeichen ist ein Verkehrszeichen ist
ein Verkehrszeichen. ;-) Dir geht es aber um den Pfosten.
Das Schild muss ja nicht an einem Pfosten oder Pfahl hängen sondern
kann genauso gut an einer Hauswand hängen oder sonstwie von oben
abgehängt sein. D.h. Du solltest für Deinen Zweck noch sowas wie
support=pole oder so ergänzen (nutze ich persönlich eher nicht, habe
ich aber schon gesehen).


 Eine Information über die Höchstgeschwindigkeit kann man gerne
 idealisieren, aber bitte kein Verkehrszeichen, das ist neben seiner
 Bedeutung nämlich bitte schön auch ein materiell vorhandener
 Gegenstand: Man kann dagegenlaufen, Girlanden oder Flyer dran
 aufhängen und so weiter.


s.o., davon kannst Du nicht pauschal ausgehen. Grundsätzlich halte ich
die Idee eines Blindenrouters für absurd, der solche Details aus OSM
nimmt, um damit sozusagen einen Autopilot für Blinde bereitzustellen.
Da braucht man definitiv ein System, das auch dynamische Hindernisse
erkennen kann (Gegenstände, die verschoben werden wie Mülltonnen, aber
auch so was wie parkende Autos), vermutlich auch sich bewegende
Gefahrenquellen wie andere Verkehrsteilnehmer einschätzt und deren
wahrscheinliche Positionen in der nahen Zukunft berechnet. Da sind
Verkehrszeichen-Masten noch das kleinste Problem.


 VerkehrsZEICHEN an Stellen, wo die nicht stehen, sind schlichtweg
 Fehler, denn die existieren da nicht.


das mache ich ja auch nicht, ich schiebe ggf. das Schild mal um einen
Meter (oder lasse das Schild, das links der (Einbahn-)Fahrbahn
zusätzlich steht, komplett weg, aber das kannst Du mit unseren Mitteln
sowieso nicht feststellen (weder GPS noch Luftbild, wo man solche
Entfernungen zwar relativ schon erkennen kann, aber absolut keine
Gewissheit hat, ob das nicht komplett 8 Meter oder so verschoben ist).


 das soll ja auch so bleiben, die Schilder sind ein zusätzlicher
 Hinweis
 aber für Autofahrer, nicht für Mapper.


ich sehe sie vor allem als Hinweis für Mapper, die Autofahrer sollten
sich auf die maxspeed-Info auf dem Way verlassen.


 doch, m.E. sind die Schilder bei Widersprüchen verlässlicher, da
 ways oft lang sind und der Mapper ggf. nicht die komplette Länge
 überprüft hat. Im Zweifel kann man natürlich auch nochmal
 hinfahren, zumindest hat man dann einen Anhaltspunkt auf mögliche
 Fehlerstellen.
 wenn jemand nochmal hinfahren muss, gehört da ein fixme dran, DAS ist
 der Anhaltspunkt für mögliche bzw. sogar bekannte Fehlerstellen
 schlechthin.


ja, kannst ja gerne ein fixme hintaggen. Wenn ich ein Schild mappe
(d.h. ich war da und habe das aufgenommen), passe ich natürlich auch
die Straße an (bzw. oft ist da noch gar kein maxspeed-Wert dran d.h.
ich setze erstmal den maxspeed). Bisher habe ich in der echten Welt
noch überhaupt nie einen diesbezüglichen Widerspruch gefunden, weil ja
auch die Mapper, die danach kommen, an den Schildern schnell erkennen
können, wo die Beschränkungen gelten :-)

Gruß Martin

___

Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.

Am 20.03.2013 17:17, schrieb Martin Koppenhoefer:
 Am 20. März 2013 14:20 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 20.03.2013 13:54, schrieb Martin Koppenhoefer:

 dafür hat man wieder das Problem, dass man die Positionen aller
 Schilder auswendig kennen muss, um die Richtigkeit zu überprüfen
 ;-)
 Klar, aber das muss ich auch, wenn da ein paar Schilder in der
 Datenbank vorhanden sind, solange ich mir nicht sicher sein kann, dass
 die dann vollständig sind.
 
 
 sehe ich nicht so, ich gehe erstmal davon aus, dass sie vollständig
 sind, und wenn ich dann zusätzliche noch nicht gemappte Schilder
 finde, mappe ich die und deren Auswirkungen halt bei Entdeckung.
Moment.
Du (oder jemand anders in diesem Thread) hat argumentiert, die Schilder
seien insbesondere dann praktisch einzutragen, wenn man eben nicht genau
weiß, wie weit die Geschwindigkeitsbegrenzung gilt.
Wenn das aber der Fall ist, dann ist genau deine Annahme nicht gegeben.

Nur weil an zwei Kreuzungen 70 ist und das auch direkt an der Kreuzung
nochmal per Schild wiederholt wird, heißt das nicht, dass dazwischen
nicht 200 Meter ohne Geschwindigkeitsbegrenzung existieren.
Genau diese Situation erzeugst du aber, wenn Du an den Kreuzungen
jeweils vorbeikommst und nur das Schild einträgst, und ich mich - deinen
Tipps folgend - daran orientiere, sehe, dass da an einer Straße zweimal
70 steht und dazwischen noch nichts eingetragen ist, und das deshalb
korrigiere.

Wenn ich DESHALB jetzt vorbeifahren muss, hat niemand was gewonnen, wenn
ich nicht vorbeifahre, produziere ich die Fehler.
 
 
 Verifizieren von OSM-Daten auf Grundlage anderer OSM-Daten, die nicht
 besser verifiziert sind (und dass die schilder-nodes besser
 verifiziert sind im Allgemeinen, wage ich mal zu bezweifeln) hilft nichts.
 
 
 kommt sicher auf die Gegend an, auf die Anzahl der Mapper, auf die
 Anzahl der erfahrenen Mapper etc., in meinem Umfeld sind die
 Schild-Positionen quasi immer richtig, maxspeed Angaben auf dem way
 dagegen sehr oft geraten oder ziemlich ungenau.
Was erneut ein Argument für eine bessere Sichtbarkeit der
maxspeed-Angaben ist, aber offensichtlich kein Argument, dass die
Schilder tatsächlich dabei helfen, die für Nutzer der Daten mutmaßlich
relevantere Angabe von maxspeed auf dem way tatsächlich korrekt zu halten.
Im Gegenteil liegt die Vermutung nahe, dass zu viele Mapper Schilder
eintragen ohne auf die maxspeed-Angaben am way zu achten (d.h. diese zu
korrigieren).
 
 
 Bestenfalls kriegt man daraus die Info, dass es inkonsistent ist,
 schlimmstenfalls gaukelt ein doppelter Fehler vor, es sei konsistent
 und deshalb vermutlich richtig.
 
 
 das kann ja immer vorkommen, irgendwann merkt es dann trotzdem jemand,
 und korrigiert es.
 
 
 Um die Richtigkeit zu überprüfen brauche ich gerade bei
 maxspeed-Angaben grundsätzlich das lokale Wissen oder eine andere
 Quelle von außen.
 
 
 m.E. sollten wir nur auf das lokale Wissen setzen, die externen
 Quellen haben auch Fehler, und sind nicht grundsätzlich verlässlicher,
 aktueller etc.. Ground-truth eben.
Klar, aber interne Daten noch viel weniger als externe, die unabhängig
von osm erfasst und ge-qualitätssichert worden sind.
 
 
 Selbst wenn die Schilder als redundante Information wirklich eine
 Hilfe wären, ist das aber kein Grund, nicht insbesondere und vorrangig
 die Visualisierung der entsprechenden way-Attribute zu forcieren, denn
 dein Verifikationsargument stimmt ja nur dann, wenn auch die sichtbar
 sind; und wenn die unsichtbar sind, gibt es auch keinen großen
 Vorteil, die Nodes sichtbar zu machen.
 
 
 ja, unbestritten, es gibt ja auch schon einen anderen Stil für JOSM,
 der genau das anzeigt.
;) gut.

Gruß
Peter

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

Re: [Talk-de] [OT] Missverständnisse 2.0: Google Maps hat Schuld an Morden?

2013-03-20 Thread Wuzzy

Die Frage »Ist Google Maps Schuld an Morden?« kann ich mit einem ganz
klarem »Nein!« beantworten.

Ich bin vom Deutschlandradio wirklich weniger reißerische Schlagzeilen
gewöhnt.

Aber das Deutschlandradio hat eh nur eine Meldung von der Huffington
Post kopiert, selbst haben sie inhaltlich nichts zu sagen. Der Artikel:
http://www.huffingtonpost.com/2013/02/11/google-earth-error-murder_n_2664042.html

Da da der eigentliche Inhalt steht, beziehe ich mich darauf.

Der Artikel liest sich so, als wäre jetzt Google dafür verantwortlich,
dass diese beiden Menschen sterben mussten, und nicht ihr Mörder. Das
ist natürlich Blödsinn.

Der größte und fahrlässigste Trugschluss in diesem Artikel (welcher bei
Deutschlandradio übernommen wird) ist diese stillschweigende Annahme,
dass die Menschen hinter einem Kartendienst (egal welchem), irgendeine
Form an Schuld oder zumindest nur eine moralische Mitschuld an den
Morden tragen, weil die Daten falsch waren.
Es ist deshalb ein Trugschluss, weil, wären die Kartendaten in diesen
Fällen korrekt gewesen, hätte es die Verwechselung nicht gegeben. Das
hieße einfach nur, dass statt den falschen die richtigen Menschen
umgebracht würden. Die Sache kann ich sogar noch ins absurde ziehen,
indem ich sie umdrehe: Wenn Meredith implizieren kann, dass
Kartenfehler Leben kosten (nämlich die Leben der irrtümlich
ermordeten), dann kann ich auch gleichzeitig behaupten, dass
Kartenfehler Leben retten (nämlich die Leben der irrtümlich _nicht_
ermordeten!).

Die Kartendaten sind höchstens nur indirekt Schuld daran, dass die
_falschen_ Menschen ermordet werden (aber was heißt DAS schon?), nicht
aber, _dass_ Menschen ermordet werden.

Da ich selber bei OpenStreetMap relativ aktiv bin, bin ich auch
einer dieser Kartenmacher. Der Artikel ging nur um Google, aber die
Rhetorik wendet sich gegen alle Kartenmacher, somit auch mich. Das kann
ich nicht auf mich sitzen lassen. Drastisch formuliert:
Mein Gewissen wöge keine Mikrogramm mehr, wenn in irgendeinem Haus
jemand irrtümlicherweise ermordet würde, weil die Hausnummer (oder
was auch immer) falsch wäre und dieser Fehler stamme von mir. Viel eher
würde ich mir ernsthafte Gedanken um die Sicherheit in meiner
Nachbarschaft machen, wenn Auftragsmörder einfach so ihr Unwesen
treiben können und so schnell wie möglich abhauen.

Zu den Themen Auftragsmörder und Moral siehe auch
Hitman Finds Morals von Third String Kicker Comedy
http://youtu.be/ZrxSiDQIrgU.


Dann dieser Satz:
 Mapping apps and services have played a role in several recent crimes
 and mishaps.
Blafasel und blablubb. Diese Aussage ist zwar sachlich absolut korrekt,
aber sie bedeutet rein gar nichts. Es ist nur Geschwafel. Eine Analogie:
Bevor es das Internet gab, gab es ausgedruckte Straßenkarten, die
(Überraschung!) auch von Mördern benutzt wurden. Trotzdem käme wohl
kaum einer auf die Idee, zu sagen, dass Straßenkarten eine Rolle in
diversen Verbrechen gespielt haben. Weil … na und? Nur weil Mörder
Straßenkarten benutzen, trifft die Ersteller der Karte keine Schuld.
Das ist bei digitalen Karten genauso, ergo ist dieser Satz
bedeutungsschwangeres Gefasel.
Zum »Zusammenhang« von Kartenanwendungen mit Verbrechen siehe auch The
Heist von Third String Kicker Comedy
http://youtu.be/PhqojNDWYxo.


Abgesehen davon müssen das alles ausgesprochen unfähige Mörder bzw.
Auftraggeber gewesen sein, denn da muss ja wirklich alles
schiefgelaufen sein:
Erstens gibt/gab es ja den bekannten Kartenfehler. Daran sind weder
Mörder noch Auftraggeber schuld.
Zweitens haben alle Mörder sich nicht die Mühe gemacht, auf die
Hausnummer (die Reale!) zu gucken, bevor sie das Haus betreten.
Drittens hätte den Mördern spätestens beim Anblick ihrer Opfer klar
sein müssen, dass sie den »falschen« auflauern, wegen anderem Aussehen
etc. Da es ihnen aber offensichtlich auch da nicht klar wurde, weist
das darauf hin, dass die Auftraggeber den Mördern wohl noch nicht mal
ein Foto oder ähnliches gegeben haben, vielleicht nur eine sehr vage
Beschreibung, noch nicht mal, wie das Haus aussieht usw.

Daran, dass es »die Falschen« erwischt hat, hat also mehr die
Stümperhaftigkeit der Mörder bzw. Auftraggeber Schuld als die der
Kartenmacher. Deshalb hab ich ein paar Absätze vorher auch nur von einer
indirekten Schuld geschrieben.

Bei dieser Art von Journalismus weiß ich, warum ich keine
Zeitungen aufschlage. Ja, ich frage mich, wozu ich eigentlich diesen
Link angeklickt habe.

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

Re: [Talk-de] Wie Buchstaben-Ergänzung bei Hausnummern mappen?

2013-03-20 Thread Wuzzy

Am Mon, 18 Mar 2013 13:02:27 +0100
schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 Es geht im Prinzip danach, was gilt, nicht, was der Mapper
 präferiert. Da das abhängig von den Landesgesetzen (und ggf. auch
 kommunal?) ist, scheint mir eine bundeseinheitliche Lösung an der
 Realität vorbeizugehen. Für Berlin habe ich die entsprechende
 Verordnung hier gefunden:
 http://www.berlin.de/ba-spandau/verwaltung/gesetze/nrvo.html

Na damit kann ich mich schon eher anfreunden. Diese Information ist
doch hervorragend für das Wiki geeignet.

Wenn es eine Regelung gäbe, würde ich mich dann eher nach der
Regelung richten, vorausgesetzt, sie ist halbwegs sinnvoll und sorgt
nicht für Verwirrung! Ich habe leider keine Ahnung, wie ich das für mein
Örtchen rausfinden kann, bzw. wie Otto-Normal-OpenStreetMapper
rausfindet, was in seiner Gegend »gilt«. Wie finde ich das raus?

Ich finde ja, ins Wiki sollte wirklich mal eine Liste von Regelungen in
D gemacht werden, um anderen Mappern dafür die Sucharbeit zu ersparen.
Das Amtsdeutsch müsste aber vorher auf Hochdeutsch übersetzt werden,
damit es auch Nicht-Beamte verstehen können. ;-) Ich kann dabei leider
nicht helfen, denn ich verstehe von solchen Rechtsdingen nichts. Eine
Darstellung in Tabellenform könnte ich mir vorstellen, mit den Spalten:
- Ort
- Link zur Original-Regelung auf Amtsdeutsch
- Case-sensitiv ja/nein/immer Großbuchstabe/immer Kleinbuchstabe
- Leerzeichen ja/nein
- und was der Amtsschimmel noch so ausgewiehert hat, in
  zusammengefasster Form
Berlin hätten wir ja schonmal abgehakt.
Findet diesen Vorschlag hier irgendjemand gut?
Ob ich den Vorschlag gut finde, weiß ich selbst noch nicht; es muss
sich erst mal zeigen, ob die diversen Regelungen überhaupt zu
gebrauchen sind.

Solange ich aber gar keine Regelung für meine Gegend kenne, bleib ich
aber bei »das mappen, wie es geschrieben steht«. Ich hatte übrigens das
Glück, dass bei allen von mir gesichteten Häusern keine
widersprüchlichen Hausnummern angebracht wurden. Bei diesem Fall würd
ich mir halt willkürrlich eine von beiden aussuchen, was natürlich
suboptimal wäre.

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

Re: [Talk-de] [OT] Missverständnisse 2.0: Google Maps hat Schuld an Morden?

2013-03-20 Thread Martin Czarkowski



Am 20.03.2013 18:43, schrieb Wuzzy:

Bei dieser Art von Journalismus weiß ich, warum ich keine
Zeitungen aufschlage. Ja, ich frage mich, wozu ich eigentlich diesen
Link angeklickt habe.

++1
dem ist wahrlich nichts mehr hinzuzufügen

Czmartin


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

[Talk-de] unangekuendigte Massenedits - Revert?

2013-03-20 Thread Masi Master


Hi,
als Fortsetztung von dem Thread unangekuendigte Massenedits aus Januar  
2013:

http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100538.html

In den letzten 19 Beiträge, ab etwa hier [1], gibt es kontroverse  
Meinungen zum Thema bicycle=yes bei highway=cycleway. Und auch relativ am  
Anfang [2] schrieb jemand, dass in Lübeck bicycle=yes für Radwege ohne  
Benutzungspflicht verwendet wird.


Aufgrund der unterschiedlichen Sichtweise/Verwendung (beim Taggen von  
Radwegen) plädiere ich für einen Revert des riesigen  
Massenedit-Changesets: 14614172

Ggf. würde es schon ausreichen, die gelöschten Tags wiederherzustellen.

Fragen:
Revert ja/nein/egal? Wer ist dafür zuständig? Oder muss/soll ich das  
selber in die Hand nehmen?


Gruß
Masi

[1]  
http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100607.html
[2]  
http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100637.html


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

Re: [Talk-de] unangekuendigte Massenedits - Revert?

2013-03-20 Thread Frederik Ramm


Hallo,

On 21.03.2013 00:10, Masi Master wrote:

Aufgrund der unterschiedlichen Sichtweise/Verwendung (beim Taggen von
Radwegen) plädiere ich für einen Revert des riesigen
Massenedit-Changesets: 14614172


+1

Der User hat sich ja auch ein paar Tage nach diesem Changeset loeschen 
lassen.



Fragen:
Revert ja/nein/egal? Wer ist dafür zuständig? Oder muss/soll ich das
selber in die Hand nehmen?


Kannst Du schon selber machen, wenn hier auf der Liste einigermassen 
Einigkeit herrscht. Mal abwarten, was die anderen sagen.


Bye
Frederik

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

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

[Talk-in] StudioX Mapping Party Diary

2013-03-20 Thread Mikel Maron

http://www.openstreetmap.org/user/mikelmaron/diary/18777


Some thoughts on a stimulating couple days...
 
* Mikel Maron * +14152835207 @mikel s:mikelmaron___
Talk-in mailing list
Talk-in@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Errori in OSM

2013-03-20 Thread Andrea Musuruane

2013/3/19 Daniele Forsi dfo...@gmail.com

 ben fatto e buona l'idea di usare l'asterisco, è un po' invadente ma
 almeno è chiaro dove sono gli spazi, mi hai fatto venire in mente
 un'alternativa: middot; http://it.wikipedia.org/wiki/Punto_mediano
 io proverò a usarlo nelle mie pagine anche se è meno evidente, ma io
 aggiungo anche la sottolineatura
 Esempio:
 *Via*A.*de*Gasperi
 ·Via·A.·de·Gasperi

  Nei giorni scorsi sono stati corretti tutti gli errori sui nomi e le
  rotatorie con doppia entrata o uscita. \o/

 continuano le pulizie di Primavera!
 ci sono altre rotatorie per il controllo che hai aggiunto sui sensi
 unici mancanti sulle entrate/uscite


Domanda da incompetente delle varie API disponibili. Ma non si riesce a
fare uno script per fixare in automatico almeno gli errori più banali? Es:
Il nome inizia con una minuscola, il nome contiene spazi ripetuti, il nome
inizia o finisce con uno spazio, il ref è scritto con degli spazi o con
SP in minuscolo, ecc. Perché così i vari mapper si concentrerebbero su
errori più difficili da correggere.

Ciao,

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

Re: [Talk-it] way avanti e indietro

Il giorno 20 marzo 2013 01:24, totera g...@hotmail.it ha scritto:

 emmexx wrote
  Eccone un esempio:
  http://www.openstreetmap.org/browse/way/24750117

 Vado OT ma approfitto per chiedervi che cosa pensate di quel layer=0, visto
 che ci sono alcuni mappatori che lo inseriscono regolarmente su ogni
 percorso.
 A me sembra che se il tag layer serve a indicare la posizione relativa in
 altezza di due o più elementi, dare un valore di layer ad elementi che non
 ne intersecano altri non ha alcun senso.


Sì, ed è solo un suggerimento per i renderer (attenzione, non è mappare
per un renderer!). Layer=0 è il valore di default; metterlo ovunque non fa
male dal punto di vista dei dati, ma è altamente inutile ed appesantisce il
db per niente.

Ciao,

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

Re: [Talk-it] Corsia per bus, taxi, moto e bici

2013-03-20 Thread Fabri

Il 19/03/2013 21:39, Martin Koppenhoefer ha scritto:
 2013/3/19 emmexx emm...@tiscalinet.it:
 Via Rubattino a Milano e' una strada a piu' corsie con quella piu' a
 destra riservata ai veicoli in oggetto:

 Id: 47423033 e 95141873

 Quali tag usare?

 Nel wiki [1] c'e' una proposta ma, a quanto pare, non e' condivisa.

 grazie
 maxx


 se guardi la strada per intera non devi specificare niente, ma se vuoi
 usare il lanes-tagging potresti usare dei tags per le corsie:
 http://wiki.openstreetmap.org/wiki/Lanes
 http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension

 ciao,
 Martin


Dunque, nell'ipotesi che sia una strada a senso unico a 3 corsie (2
normali e una all'estrema destra dedicata a bus,taxi,bici e moto)
come si mette? (dipende anche se è obbligatorio servirsi della corsia
dedicata o meno)

psv:lanes:forward=no|no|designated
bicycle:lanes:forward=yes|yes|designated
motorcycle:lanes:forward=yes|yes|designated
motorcar:lanes:forward=yes|yes|no
lanes=3
lanes:psv:forward=1

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

Re: [Talk-it] Errori in OSM

2013/3/20 Andrea Musuruane musur...@gmail.com:
 Domanda da incompetente delle varie API disponibili. Ma non si riesce a fare
 uno script per fixare in automatico almeno gli errori più banali?


qualcosa esiste, per esempio il woodpeck_fixbot (prima fixbot):
http://wiki.openstreetmap.org/wiki/List_of_Import_and_Automated_Edits_Users
Anche se credo non faccia altro che fissare problemi creati da imports
(per esempio rimuove imports problematici):
http://www.openstreetmap.org/user/woodpeck_fixbot/


 Es: Il
 nome inizia con una minuscola, il nome contiene spazi ripetuti, il nome
 inizia o finisce con uno spazio, il ref è scritto con degli spazi o con SP
 in minuscolo, ecc.


in passato c'erano spesso problemi con dei bots che facevano cose del
genere, perché spesso i confini non sono costante e si rischia di
editare cose nel estero vicino. Per esempio in Germania o in Francia
fanno il contrario per i ref (ci mettono uno spazio se no c'è). Oppure
in svizzera via in tedesco si scrive Strasse mentre in Germania si
scrive Straße, e c'erano casi dove il bot cambiava il nome in
continuazione nel sbagliato, ed ovviamente i mappatori che facevano la
correzione a mano si sono incti ;-)

Non ho trovato un bot che corregge in automatico problemi del genere
al momento (forse in Francia quello di Pieren), cosa mi fa pensare che
quel approccio non ha funzionato bene nel passato. Credo che JOSM
toglie spazi all'inizio e fine in automatico (non sono sicuro al
100%).


 Perché così i vari mapper si concentrerebbero su errori
 più difficili da correggere.


si, premesso che funzioni perfettamente si, ma altrimenti i mappatori
dovrebbero correggere in più i problemi che ha creato il bot ;-)

ciao,
Martin

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

Re: [Talk-it] Errori in OSM

dimenticavo: http://wiki.openstreetmap.org/wiki/User:Xybot

ciao,
Martin

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

Re: [Talk-it] Errori in OSM

2013-03-20 Thread Groppo O

Ciao,
Il giorno 20 marzo 2013 10:05, Andrea Musuruane musur...@gmail.com ha
scritto:

 Domanda da incompetente delle varie API disponibili. Ma non si riesce a
 fare uno script per fixare in automatico almeno gli errori più banali?


In linea di principio non sono contrario alle correzioni automatiche (anche
se non mi prendo la responsabilità di farle ;-) ma le correzioni manuali,
secondo me, hanno alcuni pregi.
- Permettono di portare altri miglioramenti alla mappa. Spesso, dove c'è un
errore se ne trovano altri, ad esempio: strade tracciate in modo
approssimativo, che passano sopra edifici, con curve spigolose, senza
ponti, attraversamenti pedonali o direzioni obbligate...
(Mi sembra che valga anche l'opposto: in una zona mappata accuratamente,
anche i nuovi mapper fanno più attenzione).
- Coinvolgono più persone, che diventano consapevoli di un certo tipo di
errore, in futuro eviteranno di farlo e magari avvertiranno altre persone
quando lo trovano.
- Permettono di accorgersi se in una zona qualche mapper continua a
reinserire gli stessi errori e va quindi avvertito.


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

Re: [Talk-it] Errori in OSM

Il giorno 20 marzo 2013 13:25, Groppo O grop...@gmail.com ha scritto:

 Ciao,
 Il giorno 20 marzo 2013 10:05, Andrea Musuruane musur...@gmail.com ha
 scritto:

 Domanda da incompetente delle varie API disponibili. Ma non si riesce a
 fare uno script per fixare in automatico almeno gli errori più banali?


 In linea di principio non sono contrario alle correzioni automatiche
 (anche se non mi prendo la responsabilità di farle ;-) ma le correzioni
 manuali, secondo me, hanno alcuni pregi.
 - Permettono di portare altri miglioramenti alla mappa. Spesso, dove c'è
 un errore se ne trovano altri, ad esempio: strade tracciate in modo
 approssimativo, che passano sopra edifici, con curve spigolose, senza
 ponti, attraversamenti pedonali o direzioni obbligate...


Mi sono trovato a bonificare i landuse di Suno, che erano agganciati ai
nodi delle strade e altre simili amenità. Tutto questo per fixare un ref
non conforme.

Ciao,

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

[Talk-it] App per sicurezza stradale

2013-03-20 Thread Fabri

http://www.sicurstrada.it/notizie/hackathon-sulla-sicurezza-stradale-e-mobilita-sostenibile/

magari si può usare osm...

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

[Talk-it] App per sicurezza stradale

2013-03-20 Thread Fabri

http://www.sicurstrada.it/notizie/hackathon-sulla-sicurezza-stradale-e-mobilita-sostenibile/

magari si può usare osm...

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

[Talk-it] corsie di accesso a casello autostradale

2013-03-20 Thread Davide Donini

Ciao lista

cosa ne dite di questa situazione?
http://www.openstreetmap.org/?lat=45.430456lon=10.702057zoom=18layers=M
è il casello di Peschiera (A4)
A me sembra un po' eccessivo mappare ogni corsia.

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

Re: [Talk-it] corsie di accesso a casello autostradale

Il giorno 20 marzo 2013 15:01, Davide Donini dvdz...@gmail.com ha scritto:

 Ciao lista

 cosa ne dite di questa situazione?
 http://www.openstreetmap.org/?lat=45.430456lon=10.702057zoom=18layers=M
 è il casello di Peschiera (A4)
 A me sembra un po' eccessivo mappare ogni corsia.


A me no: l'ho fatto io! :-D

Scherzi a parte: eccessivo no, sottoutilizzato magari sì. È un'informazione
che non stiamo usando in maniera utile.

L'unico problema che vedo con questa mappatura è che il casello potrebbe
spostare alcune corsie dal servizio di ingresso a quello di uscita, il che
significherebbe rivedere i collegamenti e i sensi unici. D'altro canto,
questa mappatura ci dice il numero *indicativo* di corsie riservate
all'ingresso o all'uscita.

Una informazione utile (ma non c'è accordo su come mapparla) è quella sulle
corsie riservate al telepass. In secondo luogo, quali servizi sono offerti
da ogni gabbiotto (solo contanti, solo carte, carte telepass e contanti,
etc.).

Ciao,

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

Re: [Talk-it] corsie di accesso a casello autostradale

Anche a me sembra eccessivo, ma può darsi che sbagli.
d'altronde non vengono segnate le singole corsie delle strade a più corsie
quindi anche qui sarebbe potuta bastare una sola way...bisogna vedere in
oltre come si comportano i navigatori in condizioni del genere.
io onestamente sono per mappare le vie parallele singolarmente solo quando
queste conducono a destinazioni diverse e/o è impossibile fisicamente
passare da una corsia all'altra. per strade a più corsie secondo me dovrebbe
bastare un tag che indichi il numero di corsie e li tipo di linea tra queste
(continua, tratteggiata) su una sola way,  ma ripeto potrei sbagliarmi



--
View this message in context: 
http://gis.19327.n5.nabble.com/corsie-di-accesso-a-casello-autostradale-tp5754026p5754044.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] corsie di accesso a casello autostradale

Il giorno 20 marzo 2013 16:26, Aury88 spacedrive...@gmail.com ha scritto:

 Anche a me sembra eccessivo, ma può darsi che sbagli.
 d'altronde non vengono segnate le singole corsie delle strade a più corsie
 quindi anche qui sarebbe potuta bastare una sola way...bisogna vedere in
 oltre come si comportano i navigatori in condizioni del genere.
 io onestamente sono per mappare le vie parallele singolarmente solo quando
 queste conducono a destinazioni diverse e/o è impossibile fisicamente
 passare da una corsia all'altra. per strade a più corsie secondo me
 dovrebbe
 bastare un tag che indichi il numero di corsie e li tipo di linea tra
 queste
 (continua, tratteggiata) su una sola way,  ma ripeto potrei sbagliarmi


In realtà queste *sono* separate fisicamente... c'è il gabbiotto e la
barriera tra una e l'altra. Conducono anche a destinazioni diverse: sulla
corsia 1 c'è il Telepass, sulla 2 Telepass e carte, sulla 3 solo carte, e
sulla 4 carte e contanti.

I navigatori (anzi i router) *potrebbero* ad esempio usare l'informazione
del Telepass. L'utente direbbe se ha o meno il Telepass, e il navigatore
manderebbe sulla corsia giusta. Non è un'informazione che sembra critica,
ma chi arriva sprovveduto alla Ghisolfa a Milano rischia di trovarsi
incanalato per Varese (magari pure in una corsia Telepass) quando invece
doveva andare verso Venezia...

Ciao,

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

[Talk-it] errore nel Indoor Mapping di un Centro Commerciale

Ciao a tutti,
Ispirato da  questo bellissimo post
https://plus.google.com/105538331374374393602/posts/aL6JhL6HRsp   sulla
pagina google plus della community italiana di OpenStreetMap, mi sono messo
a realizzare l'indoor mapping di un centro commerciale nelle mie vicinanze.
Siccome non sapevo nulla di indoor mapping, ho fatto qualche ricerca online
ed ho effettuato una specie di reverse engineering sui tag e le relazioni
utilizzate nel centro commerciale in oggetto del post su google+. 
Dopo due giorni di lavoro, tramite Josm, ecco che mi scontro con il primo
problema: non riesco a creare relazioni figlie...cioè le relazioni sono
tutte correttamente assegnate ma non riesco  a mettere queste relazioni come
figlie di un altra relazione; questa cosa l'ho dovuta risolvere tramite
Potlach2 alla fine :(.
Dovrò vedere meglio come assegnare una relazione ad un altra in josm :P
Finito questo lavoro sul primo livello interrompo la mappatura per vedere se
queste modifiche sono correttamente visualizzate dal tool osm per la
visualizzazione indoor...
Ora, da ieri sera questo tool indica la presenza nel centro commerciale di
una indoor mapping ma purtroppo indica anche che c'è un errore
guardate qui http://osmtools.org/indoor/#lat=45.62188lon=9.47464z=17  
(schiacciate con il mouse sull'area evidenziata in azzurrognolo)
Qualcuno sa dirmi dove sbaglio?
Grazie a tutti.




--
View this message in context: 
http://gis.19327.n5.nabble.com/errore-nel-Indoor-Mapping-di-un-Centro-Commerciale-tp5754060.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale

Il giorno 20 marzo 2013 17:18, Aury88 spacedrive...@gmail.com ha scritto:

 Ciao a tutti,
 Ispirato da  questo bellissimo post
 https://plus.google.com/105538331374374393602/posts/aL6JhL6HRsp   sulla
 pagina google plus della community italiana di OpenStreetMap, mi sono messo
 a realizzare l'indoor mapping di un centro commerciale nelle mie vicinanze.
 Siccome non sapevo nulla di indoor mapping, ho fatto qualche ricerca online
 ed ho effettuato una specie di reverse engineering sui tag e le relazioni
 utilizzate nel centro commerciale in oggetto del post su google+.
 Dopo due giorni di lavoro, tramite Josm, ecco che mi scontro con il primo
 problema: non riesco a creare relazioni figlie...cioè le relazioni sono
 tutte correttamente assegnate ma non riesco  a mettere queste relazioni
 come
 figlie di un altra relazione; questa cosa l'ho dovuta risolvere tramite
 Potlach2 alla fine :(.
 Dovrò vedere meglio come assegnare una relazione ad un altra in josm :P
 Finito questo lavoro sul primo livello interrompo la mappatura per vedere
 se
 queste modifiche sono correttamente visualizzate dal tool osm per la
 visualizzazione indoor...
 Ora, da ieri sera questo tool indica la presenza nel centro commerciale di
 una indoor mapping ma purtroppo indica anche che c'è un errore
 guardate qui http://osmtools.org/indoor/#lat=45.62188lon=9.47464z=17
 (schiacciate con il mouse sull'area evidenziata in azzurrognolo)
 Qualcuno sa dirmi dove sbaglio?
 Grazie a tutti.


In questo momento non posso controllare la tua relazione. Ti segnalo solo
che in JOSM per aggiungere una relazione come membro di un'altra relazione
(ma anche per modificarne i tag senza bisogno di aprire l'editor) basta
doppio-cliccare sulla relazione nella lista delle relazioni. I membri
diventeranno evidenziati in rosa (stile di default), e nella finestra dei
tag vedrai i tag della relazione. A quel punto, apri con l'editor la
relazione madre, e fai aggiungi membro nel modo normale.

Ciao,

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

Re: [Talk-it] corsie di accesso a casello autostradale

beh, sono separate fisicamente dal casello solo per un brevissimo tratto
mentre qui le way sono singolarmente segnate da ben prima l'inizio e ben
dopo la fine della separazione fisica ;)
per destinazioni diverse intendevo che poi le strade non si ricongiungono
più...qui è un po' diversa la cosa...non so se capite cosa intendo. 
comunque sia se fosse una mappatura lecita dobbiamo secondo me decidere se
modificare tutti i caselli autostradali in maniera coerente...IMHO non
possiamo permetterci mappature così disomogenee sul territorio nazionale e
per strade così importanti come le autostrade.
c'è sempre il problema dei caselli che possono venir assegnati ad uno o
l'altra direzione in base al traffico (so che per alcuni c'è una variazione
dalla mattina alla sera dei giorni lavorativi). direi che quest'ultimo punto
è un problema che non si pone per i telepass che sono posti di solito in
estrema destra ed assegnati fissi quindi ad un solo senso di circolazione.



--
View this message in context: 
http://gis.19327.n5.nabble.com/corsie-di-accesso-a-casello-autostradale-tp5754026p5754068.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale

grazie Simone,
ora capisco perchè non trovavo il modo per aggiungerle xD
non so, preferisco il metodo messo a disposizione da potlach2...mi sembra
più intuitivo veloce e semplice :)
si vede che sono ancora un novizio xD
grazie mille ancora!




--
View this message in context: 
http://gis.19327.n5.nabble.com/errore-nel-Indoor-Mapping-di-un-Centro-Commerciale-tp5754060p5754070.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Fuochi San Giuseppe Itri su OSM

mi associo anche io ai complimenti!
ottima idea e iniziativa



--
View this message in context: 
http://gis.19327.n5.nabble.com/Fuochi-San-Giuseppe-Itri-su-OSM-tp5753861p5754071.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] corsie di accesso a casello autostradale

Il giorno 20 marzo 2013 17:48, Aury88 spacedrive...@gmail.com ha scritto:

 beh, sono separate fisicamente dal casello solo per un brevissimo tratto
 mentre qui le way sono singolarmente segnate da ben prima l'inizio e ben
 dopo la fine della separazione fisica ;)

per destinazioni diverse intendevo che poi le strade non si ricongiungono
 più...qui è un po' diversa la cosa...non so se capite cosa intendo.


Sì, lo so, stavo leggermente trollando ;-)


 comunque sia se fosse una mappatura lecita dobbiamo secondo me decidere se
 modificare tutti i caselli autostradali in maniera coerente...IMHO non
 possiamo permetterci mappature così disomogenee sul territorio nazionale e
 per strade così importanti come le autostrade.


Concordo. Ma del resto non coincide neanche la mappatura dei caselli e
delle uscite (barrier=toll_booth, building=toll_both, nome sì / nome no,
nome solo sull'uscita dall'autostrada...).


 c'è sempre il problema dei caselli che possono venir assegnati ad uno o
 l'altra direzione in base al traffico (so che per alcuni c'è una variazione
 dalla mattina alla sera dei giorni lavorativi). direi che quest'ultimo
 punto
 è un problema che non si pone per i telepass che sono posti di solito in
 estrema destra ed assegnati fissi quindi ad un solo senso di circolazione.


Di solito ma non sempre: vedi la già citata barriera della Ghisolfa, a
Milano Ovest, che ha il telepass sulla sinistra. Lì però la separazione tra
i sensi di marcia è data da un newjersey che se non sbaglio è di cemento,
quindi è piuttosto permanente.

Ciao,

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

Re: [Talk-it] corsie di accesso a casello autostradale

2013-03-20 Thread Giovanni Caudullo

Ciao,
proposta: invece di fare le corsie che non sono comunicanti, perchè non
fare un'area a copertura di tutto il piazzale?
G


Il giorno 20 marzo 2013 17:59, Simone Saviolo simone.savi...@gmail.com ha
scritto:

 Il giorno 20 marzo 2013 17:48, Aury88 spacedrive...@gmail.com ha
 scritto:

 beh, sono separate fisicamente dal casello solo per un brevissimo tratto
 mentre qui le way sono singolarmente segnate da ben prima l'inizio e ben
 dopo la fine della separazione fisica ;)

 per destinazioni diverse intendevo che poi le strade non si ricongiungono
 più...qui è un po' diversa la cosa...non so se capite cosa intendo.


 Sì, lo so, stavo leggermente trollando ;-)


 comunque sia se fosse una mappatura lecita dobbiamo secondo me decidere se
 modificare tutti i caselli autostradali in maniera coerente...IMHO non
 possiamo permetterci mappature così disomogenee sul territorio nazionale e
 per strade così importanti come le autostrade.


 Concordo. Ma del resto non coincide neanche la mappatura dei caselli e
 delle uscite (barrier=toll_booth, building=toll_both, nome sì / nome no,
 nome solo sull'uscita dall'autostrada...).


 c'è sempre il problema dei caselli che possono venir assegnati ad uno o
 l'altra direzione in base al traffico (so che per alcuni c'è una
 variazione
 dalla mattina alla sera dei giorni lavorativi). direi che quest'ultimo
 punto
 è un problema che non si pone per i telepass che sono posti di solito in
 estrema destra ed assegnati fissi quindi ad un solo senso di circolazione.


 Di solito ma non sempre: vedi la già citata barriera della Ghisolfa, a
 Milano Ovest, che ha il telepass sulla sinistra. Lì però la separazione tra
 i sensi di marcia è data da un newjersey che se non sbaglio è di cemento,
 quindi è piuttosto permanente.

 Ciao,

 Simone

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


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

Re: [Talk-it] corsie di accesso a casello autostradale

Simone Saviolo wrote
 Sì, lo so, stavo leggermente trollando ;-)

XD

 Concordo. Ma del resto non coincide neanche la mappatura dei caselli e
 delle uscite (barrier=toll_booth, building=toll_both, nome sì / nome no,
 nome solo sull'uscita dall'autostrada...).

il fatto che già non ci sia omogeneità nella mappatura non ci autorizza ad
inserire ulteriori disomogeneità :P

[ot]purtroppo, come ho già avuto modo di dire in passato, il pregio di osm è
il fatto di essere completamente libero nell'assegnazione dei tag, ma questo
è anche un suo grande difetto.[/ot]




--
View this message in context: 
http://gis.19327.n5.nabble.com/corsie-di-accesso-a-casello-autostradale-tp5754026p5754076.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] corsie di accesso a casello autostradale

questa potrebbe essere una bella idea, ma come facciamo per il senso unico ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/corsie-di-accesso-a-casello-autostradale-tp5754026p5754077.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] corsie di accesso a casello autostradale

2013-03-20 Thread Luca Delucchi

Il 20 marzo 2013 18:19, Giovanni Caudullo
giovanni.caudu...@gmail.com ha scritto:
 Ciao,
 proposta: invece di fare le corsie che non sono comunicanti, perchè non fare
 un'area a copertura di tutto il piazzale?

non mi sembra una buona idea, quello è l'uso del suolo non la
viabilità, esistono molte corsie a sto punto tutte le strade
dovrebbero diventare aree. Cerchiamo di fare le cose semplici.
L'attuale mappatura non è corretta, le way dovrebbero separarsi molto
più vicino al casello per il discorso sopra, ogni way dev'essere
divisa dall'altra da qualcosa di insuperabile e non da una linea
tratteggiata o continua.

 G


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [Talk-it] Da domani scatta l'open by default sui siti italiani

sarchittuorg wrote
 http://www.quickmeme.com/meme/3tf3lv/
 
 Preparare i wget, puntare, mirare, fuoco!
 
 :P
 
 Ciao,
 Stefano

X.D

comunque sia come al solito in Italia le norme anche quelle buone creano
solo confusione...liberano i dati ma non si sa ancora di preciso con che
licenza 




--
View this message in context: 
http://gis.19327.n5.nabble.com/Da-domani-scatta-l-open-by-default-sui-siti-italiani-tp5753710p5754081.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] way avanti e indietro

2013-03-20 Thread Alexander Roalter


Am 20.03.2013 19:49, schrieb girarsi:

Il 20/03/2013 10:39, Simone Saviolo ha scritto:

Sì, ed è solo un suggerimento per i renderer (attenzione, non è mappare
per un renderer!). Layer=0 è il valore di default; metterlo ovunque non fa
male dal punto di vista dei dati, ma è altamente inutile ed appesantisce il
db per niente.


Sì, ok, appesantisce, però per esempio per mappare un ponte, viene
richiesto.

ma viene richiesto solo per i way con il layer ≠ 0
Se ho una strada sopra un’altra, devo solo dare layer=1 alla strada che 
passa sopra. Niente altro è richiesto: non è necessario layer=0 alla 
strada in fondo, e neanche layer=−1



--
cheers,
Alex

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

Re: [Talk-it] corsie di accesso a casello autostradale

2013-03-20 Thread Alessandro

Non mi pare troppo sbagliata, cerchiamo di mappare in maniera più
oggettiva possibile.

Alessandro

Il giorno Wed, 20 Mar 2013 15:01:00 +0100
Davide Donini dvdz...@gmail.com ha scritto:

 Ciao lista
 
 cosa ne dite di questa situazione?
 http://www.openstreetmap.org/?lat=45.430456lon=10.702057zoom=18layers=M
 è il casello di Peschiera (A4)
 A me sembra un po' eccessivo mappare ogni corsia.
 
 Davide


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

[Talk-it] Dubbio su fotografo

2013-03-20 Thread Gianluca Boero

Tempo fa ho inserito un tag per un laboratorio fotografico, usando 
craft=photografic_laboratory essendoci l'elaborazione delle immagini, 
sia istantanea sia da parte dell'esercente.
il mio dubbio è che pratica anche la vendita di prodotti fotografici. 
Non trovo nel wiki una voce adatta alla fotografia sotto shop.


--
Gianluca Boero


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

Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale

2013-03-20 Thread sabas88

Il giorno 20 marzo 2013 17:18, Aury88 spacedrive...@gmail.com ha scritto:


 Qualcuno sa dirmi dove sbaglio?


Dai una occhiata qua https://github.com/yarl/osmtools-indoor

Purtroppo non mi sono dilettato ancora :(


 Grazie a tutti.



Ciao,
Stefano



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/errore-nel-Indoor-Mapping-di-un-Centro-Commerciale-tp5754060.html
 Sent from the Italy General mailing list archive at Nabble.com.

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

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

[Talk-it] Ingrandmento mappa sul sito openstreetmap

2013-03-20 Thread girarsi

Vi risulta possibile ingrandire oltre i 30 Mt la mappa sul sito di 
openstreetmap, senza ricorrere all'uso dell'editor?


In quanto mi riesce difficile vedere alcuni dettagli/nomi inseriti con 
l'editor.


grazie a chi mi risponderà.

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

Re: [Talk-it] Dubbio su fotografo

2013-03-20 Thread Damjan Gerl


20.03.2013 - 21:40 - Gianluca Boero:

Tempo fa ho inserito un tag per un laboratorio fotografico, usando
craft=photografic_laboratory essendoci l'elaborazione delle immagini,
sia istantanea sia da parte dell'esercente.
il mio dubbio è che pratica anche la vendita di prodotti fotografici.
Non trovo nel wiki una voce adatta alla fotografia sotto shop.



shop=photo
http://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dphoto

Ciao
Damjan

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

Re: [Talk-it] [Talk-it-trentino] Ingrandmento mappa sul sito openstreetmap

2013-03-20 Thread Luca Delucchi

Il 20 marzo 2013 22:51, girarsi gira...@gmail.com ha scritto:
 Vi risulta possibile ingrandire oltre i 30 Mt la mappa sul sito di
 openstreetmap, senza ricorrere all'uso dell'editor?


non che io sappia

 In quanto mi riesce difficile vedere alcuni dettagli/nomi inseriti con
 l'editor.

 grazie a chi mi risponderà.


di nulla

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale





Am 20/mar/2013 um 17:26 schrieb Simone Saviolo simone.savi...@gmail.com:

 basta doppio-cliccare sulla relazione nella lista delle relazioni. I membri 
 diventeranno evidenziati in rosa (stile di default), e nella finestra dei tag 
 vedrai i tag della relazione. A quel punto, apri con l'editor la relazione 
 madre, e fai aggiungi membro nel modo normale. 


oppure fai un click destro nella finestra proprietà (quella con i tags) sotto a 
memberships (le relazioni) su la relazione è scegli seleziona relazione

poi la aggiungi come descritto da Simone nel relation editor della relazione 
madre

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

Re: [Talk-dk] Bygninger

2013-03-20 Thread Rasmus Vendelboe

Er det bare en hensigtserklæring du har fået, eller har du fået GST til at
lave en seperat licens til OSM? Kan vi se den?

Krediteringen (ps. dato på datasættet skal med ved kreditering jf. GST's
licenskrav) er jo bare en delmængde  af problemet [#]. Har du taget hånd om
f.eks.:

1. Ovennævnte vilkår gælder også, såfremt brugeren videregiver data
fra Geodatastyrelsen
til tredjepart.
Det kan ikke garanteres.
2. Det skal sikres, at brug af data er i overensstemmelse med dansk ret.
Hvordan gør vi det. OSM befinder sig i første omgang ikke i DK, editeres
også af ikke-danskere uden for DK, og er derfor nok ikke underlagt dansk
lov.
3. Myndigheden kan til enhver tid ændre brugsretten til data og vilkårene
herfor.
Vi kan vel ikke acceptere en massesletning af data fordi GST får nye ideer.


[#] http://www.gst.dk/Emner/Frie_data/Vilkaar/


Er det en gene


Med venlig hilsen
Rasmus Vendelboe


2013/3/19 Soren Johannessen soren.johannes...@gmail.com

  1. Har vi en reel tilladelse til at importere FOT data? I et format der
 kan
  arkiveres og vises frem på wikien. På kortforsyningen var der ingen
  licensinformation da jeg downloadede data.
 Hej Jonas

 Tina Svan Colding fra Geodatastyrelsen har i en personlig mail sagt
 god for kun at benytte kreditering på databaseniveau i OpenStreetMap.
 At hvert geografisk objekt OSM benytter fx en bygning får noget i stil
 med

 source=Geodatastyrelsen - FOT (evt. årstal)

 Der udover har Tina spurgt om evt. Geodatastyrelsen kunne nævnes på
 http://www.openstreetmap.org/copyright  under Vores bidragydere da
 andre  landes kortlægningsagenturer også bliver nævnt (sidst punkt
 sættes i værk når evt. bygningsimport er i gang).

 Peter Brodersen og jeg var i efteråret ude hos daværende KMS og
 fortælle lidt om hele OSM dataflowet samt at nævnte selvfølgelig at
 OSM ikke kan gøres ansvarlig for, hvor data ender henne. Dette punkt
 har jeg også i  januar mail påpeget over for Geodatastyrelsen igen, da
 jeg spurgte om hvordan kreditering skulle ske. Det punkt er
 Geodatastyrelsen helt med på og orienteret om.  Så vores
 krediteringsmåde i source tagget overholder deres betingelser for
 brug jfr. mail fra Tina Svan Colding.

 Så der er kun at sige order to go til evt. bygningsimport.

 vh
 Søren Johannessen
















  2. Før 1. var på plads har jeg ikke rigtig villet give mig i kast med at
  skrive om importen på imports@ listen.
  3. Jeg skal have eksperimenteret med forenkling af FOT data der til tider
  har alt for mange nodes (flere hundrede nodes for en silo er vildt i
  overkanten).
 
  --
  Jonas Häggqvist
  rasher(at)rasher(dot)dk
 
 
  ___
  Talk-dk mailing list
  Talk-dk@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-dk

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

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

Re: [Talk-dk] Bygninger

2013-03-20 Thread Soren Johannessen

 Er det bare en hensigtserklæring du har fået, eller har du fået GST til at
 lave en seperat licens til OSM? Kan vi se den?

 Krediteringen (ps. dato på datasættet skal med ved kreditering jf. GST's
 licenskrav) er jo bare en delmængde  af problemet [#]. Har du taget hånd om
 f.eks.:


 1. Ovennævnte vilkår gælder også, såfremt brugeren videregiver data fra
 Geodatastyrelsen til tredjepart.
 Det kan ikke garanteres.
 2. Det skal sikres, at brug af data er i overensstemmelse med dansk ret.
 Hvordan gør vi det. OSM befinder sig i første omgang ikke i DK, editeres
 også af ikke-danskere uden for DK, og er derfor nok ikke underlagt dansk
 lov.
 3. Myndigheden kan til enhver tid ændre brugsretten til data og vilkårene
 herfor.
 Vi kan vel ikke acceptere en massesletning af data fordi GST får nye ideer.

Hej Rasmus

Relevante issues - vedr. at GST måske ændrer licensen for FOT brug i
fremtiden - betyder ikke at allerede brugt FOT skal trækkes tilbage
fra OSM ved en massesletning. Sådan sker tingene ikke med
tilbagevirkende kraft.

Vedr. hvor OSM data befinder (moderdatabase i UK)  sig og spredning,
GST er orienteret om dette forhold.

Jeg vil maile og spørge om GTSs kommunikation med mine spørgsmål vedr.
kreditering må offentliggøres som en PDF. Så må det dokument virke som
juridisk bindende dokument samt at OSM så er i god tro.

Og ganske rigtigt licens er sgu ikke nemt at blive klog på, hvis man
kigger sig blind på teksten fulde ordlyd

vh
Søren Johannessen

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

Re: [Talk-dk] Bygninger

2013-03-20 Thread Hans Gregers Petersen

19. mar. 2013 18.07 skrev Jonas Häggqvist ras...@rasher.dk:
 3. Jeg skal have eksperimenteret med forenkling af FOT data der til tider
 har alt for mange nodes (flere hundrede nodes for en silo er vildt i
 overkanten).

I al ydmyghed, vil jeg foreslå, at du negligerer dette punkt.

Der er i FOT ganske tydelige regler for registreringen, så
nøjagtigheden overholdes, og så vidt jeg husker skal siloer i
OP3-områder (udenfor byerne) overholde den almene 1 meters
nøjagtighed. Således vil punktet maksimalt afvige 1 meter fra det
faktiske fotogrammetriske punkt. På ganske store siloer, vil der
derfor kunne forekomme en del punkter - men det vigtige er at
nøjagtigheden her ikke er anderledes end for huse i samme OP (siloer
har bare desværre ofte runde geometrier - hvor vores mere
almindelige bygninger har en tendens til at være rektangulære).

Som jeg ser det er det ikke anderledes end enhver anden indtegning,
hvor nogle folk meget tydeligt overregistrerer vejmidter gennem
sving eller værre endnu indfører punkter for hver X meter på lige
strækninger.

Min pointe er, at hvis det kan spare dig/nogen noget arbejde, og hvis
det i virkeligheden er et ikke-problem (som jeg opfatter det som), så
ville jeg personligt hellere bruge tiden på noget andet end at
forenkle data. :-)


Mvh

Gregers


(Mit gæt er i øvrigt at der vil være ganske få OP1-siloer (siloer
indenfor bygrænserne), hvor registreringsnøjagtigheden i stedet er
30cm.)

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

Re: [Talk-es] Nueva ortofoto Euskadi

2013-03-20 Thread Iván Sánchez Ortega

On Lunes, 18 de marzo de 2013 08:42:16 Gari Araolaza escribió:
 Aviso de que ya está disponible la nueva ortofoto de Euskadi,
 correspondiente al 2012.
 
 http://www.geo.euskadi.net/publicada-la-ortofoto-de-2012-de-25cm/s69-geonot
 /es/
 
 Actualicen sus WMS!

Al parecer, los chicos del IGN han añadido estas nuevas ortos al WMS del PNOA:

http://www.ign.es/PNOA_WMS/

-- 
Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Pierre-Alain Dorange

Pieren pier...@gmail.com wrote:

 C'est quand même incroyable de devoir dépendre d'un projet externe
 (wikipedia) qui lui n'hésite pas à nommer les choses par leur nom
 (wikipedia=fr:Arrondissement de Caen) pour compenser les
 tergiversations de quelques contributeurs OSM.

Bon hier soir j'ai expérimenté et j'ai osé nommé l'Arrondissement de
Cognac en Arrondissement de Cognac (au lieu de Cognac) et bien voilà
Nominatim ne s'embrouille plus et la recherche Cognac me retourne
dsormais la ville en premier, suivi de la gare (nommé Cognac
seuelement, faudra-t'il aussi la nommer Gare de Cognac ?) puis la
hameau Cognac qui porte bien son nom.

-- 
Pierre-Alain Dorange
OSM experiences : http://www.leretourdelautruche.com/map/


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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

2013-03-20 Thread Tony Emery

verdy_p wrote
tu nommes la rue du nom du lotissement (tant pis si cela concerne
plusieurs rues proches.

Je ne suis pas trop d'accord car :
- il y a des voies qui appartiennent à des lotissements et qui, elles, sont
nommées. Donc pas de distinctions possibles entre ces 2 types de voies.
- il ne s'agit pas du nom de la rue mais d'une localisation c'est la rue
qui est dans le lotissement tartampion

verdy_p wrote
Maintenant addr:street n'est effectivement pas le meilleur choix pour
indiquer en fait un secteur, un bloc (on devrait plutôt indiquer un
autre élément addr:*=* et malgré tout pouvoir former une relation non
linéaire avec, càd une surface). Du coup si on met des numéros de
maisons, on se demande quel est lintérêt d'associer un nom de rue
puisque le noeud ou la maison désignée sera dans la surface couverte.

addr:street n'est peut-être pas le meilleur choix pour indiquer un secteur,
mais c'est le seul (je crois) qui est utilisé par OSM pour faire le lien
avec l'adresse.

verdy_p wrote
On devrait donc pouvoir créer un polygone avec un rôle place=* adapté
aux lieux-dits. et mettre addr:place=* pour indiquer ce nom de
polygone/surface, et cela suffirait en plus du numéro de maison même
si aucune rue n'est indiquée. Un peu aussi comme les numéros (ou
lettres) de bâtiments dans une résidence privée, qui sont aussi dans
le même cas : le numéro de bâtiment suffit au sein du polygone de la
résidence qui donne le nom de la résidence.

J'avais effectivement pensé à place=subdivision, mais, du coup, le nom
n'apparaît pas dans OSM. Pour qualifier les lotissements, je verrais plutôt
un landuse=residential, residential=subdivision et name=*.

Le SDIS 83 et l'Association des Maires du Var ont réalisé un guide assez
complet sur l'adressage. Voici le site qui en parle :
http://www.amv83.com
http://www.amv83.com/index.php?option=com_contentview=articleid=1249:lamf83-la-poste-le-sdis83-et-la-ddfip-publient-un-guide-special-qadressageqcatid=299:a-la-uneItemid=419

Et le document est téléchargeable ici en pdf
http://www.amv83.com/images/stories/actu/adressage2011.pdf?e383221221533f9b647b296961eac082=be0e01de840549d6a875a5e347a01214

--
View this message in context:
http://gis.19327.n5.nabble.com/Rues-sans-nom-dans-les-lotissements-et-adressage-tp5753877p5753953.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Les canaux de navigation

2013-03-20 Thread ades_...@orange.fr

tu peux m'envoyer le fruit de ton labeur en pièce jointe…
Le 19 mars 2013 à 23:32, Jo. a écrit :

 Merci, ce serait avec plaisir demain je vais réfléchir à tête reposée 
 comment faire un premier passage avec un traducteur automatique sans casser 
 les balises utilisée pour le wiki (mise en forme). Il me restera un travail 
 de reformulation de pĥrase et me connaissant il y aura quelques « fote d'or 
 taux graphe est de gramme mère » ;-/
 
 
 
 Le 19 mars 2013 22:04, ades_...@orange.fr ades_...@orange.fr a écrit :
 
 Le 19 mars 2013 à 21:11, Jo. a écrit :
 
  Je vais faire un essais de traduction... mon anglais est dramatique mais si 
  on attends une traduction parfaite du premiers coup on risque d'attendre 
  longtemps ;-)
 
  La traduction s'améliorera avec la temps et il faut bien commencé par un 
  bout...
 je veux bien donner un coup de main… le résultat risque de ne pas être triste 
 ;-)
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Christian Quest

Le 20 mars 2013 08:04, Pierre-Alain Dorange pdora...@mac.com a écrit :
 Bon hier soir j'ai expérimenté et j'ai osé nommé l'Arrondissement de
 Cognac en Arrondissement de Cognac (au lieu de Cognac) et bien voilà
 Nominatim ne s'embrouille plus et la recherche Cognac me retourne
 dsormais la ville en premier, suivi de la gare (nommé Cognac
 seuelement, faudra-t'il aussi la nommer Gare de Cognac ?) puis la
 hameau Cognac qui porte bien son nom.


Ca me semble assez logique d'appeler un chat un chat et donc un
arrondissement un arrondissement.
Toutefois, conserver un libellé simple sans la mention
arrondissement peut aussi être utile (exemple pour une carte des
sous-préfectures et de leur arrondissement où on ne va pas répéter
Arrondissement de sans arrêt).

Pour les gares (ou autre) ça mérite aussi réflexion... et on a un
problème similaire. Lors de telle utilisation Gare de Machin sera
utile (exemple avec Nominatim), mais pour une autre réutilisation
Machin sera nécessaire. Exemple sur un rendu de carte où il y a une
icône qui symbolise la gare, donc où il est inutile de le répéter dans
le texte qui n'a jamais assez de place pour être placé.

Dans tout les cas, il faudrait harmoniser et ne pas perdre de vue ce
qui est fait hors hexagone.

Entre name, official_name, short_name on va bien trouver de quoi
conserver les différentes variantes de nom qui ont chacune une utilité
et qu'on ne peut pas toujours déterminer automatiquement.

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

2013-03-20 Thread Romain MEHUT

Le 20 mars 2013 08:25, Tony Emery tony.em...@yahoo.fr a écrit :


 addr:street n'est peut-être pas le meilleur choix pour indiquer un secteur,
 mais c'est le seul (je crois) qui est utilisé par OSM pour faire le lien
 avec l'adresse.


Il existe aussi http://wiki.openstreetmap.org/wiki/Key:addr:place et sur la
liste il y a déjà eu une discussion à ce sujet avec aussi un addr:hamlet

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Vincent Pottier


Le 20/03/2013 08:04, Pierre-Alain Dorange a écrit :

Pieren pier...@gmail.com wrote:


C'est quand même incroyable de devoir dépendre d'un projet externe
(wikipedia) qui lui n'hésite pas à nommer les choses par leur nom
(wikipedia=fr:Arrondissement de Caen) pour compenser les
tergiversations de quelques contributeurs OSM.

Bon hier soir j'ai expérimenté et j'ai osé nommé l'Arrondissement de
Cognac en Arrondissement de Cognac (au lieu de Cognac) et bien voilà
Nominatim ne s'embrouille plus et la recherche Cognac me retourne
dsormais la ville en premier, suivi de la gare (nommé Cognac
seuelement, faudra-t'il aussi la nommer Gare de Cognac ?) puis la
hameau Cognac qui porte bien son nom.



Pourquoi faut-il ajouter gare dans le nom alors qu'il y a railway=station
C'est comme porter une ceinture et des bretelles.
Si l’algorithme ne s'y retrouve pas c'est l’algorithme qu'il faut changer.
--
FrViPofm

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Francescu GAROBY

Je rejoins Vincent : les arrondissements comme les gares ne devraient pas
se nommer arrondissement de .../gare de ... ou alors changeons aussi les
communes en commune de ... !

Francescu


Le 20 mars 2013 08:54, Vincent Pottier vpott...@gmail.com a écrit :

 Le 20/03/2013 08:04, Pierre-Alain Dorange a écrit :

  Pieren pier...@gmail.com wrote:

  C'est quand même incroyable de devoir dépendre d'un projet externe
 (wikipedia) qui lui n'hésite pas à nommer les choses par leur nom
 (wikipedia=fr:Arrondissement de Caen) pour compenser les
 tergiversations de quelques contributeurs OSM.

 Bon hier soir j'ai expérimenté et j'ai osé nommé l'Arrondissement de
 Cognac en Arrondissement de Cognac (au lieu de Cognac) et bien voilà
 Nominatim ne s'embrouille plus et la recherche Cognac me retourne
 dsormais la ville en premier, suivi de la gare (nommé Cognac
 seuelement, faudra-t'il aussi la nommer Gare de Cognac ?) puis la
 hameau Cognac qui porte bien son nom.


 Pourquoi faut-il ajouter gare dans le nom alors qu'il y a railway=station
 C'est comme porter une ceinture et des bretelles.
 Si l’algorithme ne s'y retrouve pas c'est l’algorithme qu'il faut changer.
 --
 FrViPofm


 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr




-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Christian Quest

Le 20 mars 2013 08:54, Vincent Pottier vpott...@gmail.com a écrit :

 Pourquoi faut-il ajouter gare dans le nom alors qu'il y a railway=station
 C'est comme porter une ceinture et des bretelles.
 Si l’algorithme ne s'y retrouve pas c'est l’algorithme qu'il faut changer.

Il n'est pas toujours possible de calculer ces noms automatiquement et
surtout sans faire d'erreur.

Gare de
Gare du
Gare d'

Gérer correctement les H aspirés ou muets est une galère...

Le diable se cache dans les détails... et les exceptions ;)

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

Le 20 mars 2013 09:03, Francescu GAROBY windu...@gmail.com a écrit :
 Je rejoins Vincent : les arrondissements comme les gares ne devraient pas se
 nommer arrondissement de .../gare de ... ou alors changeons aussi les
 communes en commune de ... !

Sans oulier aussi les départements qu portent aussi le nom des
fleuves... Ce renommage qui ne sert qu'à régler un problème de tri des
résutlats sur Nominatim (lequel de toute façon fait parfaitement la
différence dans ses résultats en les affichant bel et bien
différemment même si la requête est ambiguë et fait apparaitre
plusieurs possibilités,) c'est vraiement taguer pour le rendu.

Pas besoin de Arrrondissement de, pas plus que Département de,
Commune de, Région de, Canton de ... même si Nominatim parfois
calcule mal sa pertinence (parce qu'il utilise des règles empiriques
assez farfelues pour son classement, ce qui pourtant n'entraine aucune
confusion).

Wikipédia est obligé de mettre une précision dans son titre car il n'a
pas moyen de faire autrement, chaque titre devant être unique, sinon
il crée une page d'homonymie et oblige l'utilisateur à aller d'abord
sur cette page pour choisir un des liens proposés..

Si un utilisateur fait une recherche sur Nominatim et obtient
plusieurs résulats, et que ces résultats sont justes, mais seulement
pas triés de la façon à laquelle il s'atend simplement parce qu'il ne
sait pas lire ces résultats et voudrait absolument que le seul
résultat qui l'intéresse doit (pour lui seulement) être le premier de
la liste, c'est l'utilisateur qui a un problème... de paresse surtout
(car il n'a surtout pas envie de lire les libellés affichés ni même de
regarder, s'il a un doute, sur le lien détails !

Il n'est pas anormal que Nominatim permette de rechercher plein de
choses : des villes, des arronidissements, des gares, des stations de
bus ou métro. Nominatim les diffférencie sans problème même s'il
affiche plusieurs résultats.

Et puis Nominatim n'est pas le seul concerné, c'est un rendu
particulier. Mêmme l'insee ne met pas Arrondissement de  dans sa
base.

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread JB

 

T't't'… 

Ce n'est toujours pas parce que l'algorithme n'est pas
parfait (aujourd'hui) qu'il faut modifier toute la base en conséquence.
Tagguer pour le rendu, on ne s'en rend plus toujours compte quand on y
est jusqu'au nez (dans le rendu) ? 

JB. 

Le 20.03.2013 09:11,
Christian Quest a écrit : 

 Le 20 mars 2013 08:54, Vincent Pottier
vpott...@gmail.com a écrit :
 
 Pourquoi faut-il ajouter gare dans
le nom alors qu'il y a railway=station C'est comme porter une ceinture
et des bretelles. Si l'algorithme ne s'y retrouve pas c'est l'algorithme
qu'il faut changer.
 
 Il n'est pas toujours possible de calculer ces
noms automatiquement et
 surtout sans faire d'erreur.
 
 Gare de

Gare du
 Gare d'
 
 Gérer correctement les H aspirés ou muets est une
galère...
 
 Le diable se cache dans les détails... et les exceptions
;)

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

Le 20 mars 2013 08:25, Tony Emery tony.em...@yahoo.fr a écrit :
 verdy_p wrote
 tu nommes la rue du nom du lotissement (tant pis si cela concerne
 plusieurs rues proches.

 Je ne suis pas trop d'accord car :
 - il y a des voies qui appartiennent à des lotissements et qui, elles, sont
 nommées. Donc pas de distinctions possibles entre ces 2 types de voies.

Je sais, mais cela ne change pas le problème quand la rue elle-même
n'a pade d nom et que les adresses sont numérotées pour tout le
lotissement.

 - il ne s'agit pas du nom de la rue mais d'une localisation c'est la rue
 qui est dans le lotissement tartampion

On est dans le même cas cavec les numéros de batiments dans une
résidence privée, qui ne met pas de nom à ses voies internes, et
numérote les bâtiments globalement dans toute la résidence.

 Maintenant addr:street n'est effectivement pas le meilleur choix pour
 indiquer en fait un secteur, un bloc (on devrait plutôt indiquer un
 autre élément addr:*=* et malgré tout pouvoir former une relation non
 linéaire avec, càd une surface). Du coup si on met des numéros de
 maisons, on se demande quel est lintérêt d'associer un nom de rue
 puisque le noeud ou la maison désignée sera dans la surface couverte.

 addr:street n'est peut-être pas le meilleur choix pour indiquer un secteur,
 mais c'est le seul (je crois) qui est utilisé par OSM pour faire le lien
 avec l'adresse.

Il faudrait pourtant utiliser autre chose que addr:street=* pour
nommer les secteurs/blocs...

 verdy_p wrote
 On devrait donc pouvoir créer un polygone avec un rôle place=* adapté
 aux lieux-dits. et mettre addr:place=* pour indiquer ce nom de
 polygone/surface, et cela suffirait en plus du numéro de maison même
 si aucune rue n'est indiquée. Un peu aussi comme les numéros (ou
 lettres) de bâtiments dans une résidence privée, qui sont aussi dans
 le même cas : le numéro de bâtiment suffit au sein du polygone de la
 résidence qui donne le nom de la résidence.

 J'avais effectivement pensé à place=subdivision, mais, du coup, le nom
 n'apparaît pas dans OSM. Pour qualifier les lotissements, je verrais plutôt
 un landuse=residential, residential=subdivision et name=*.

Les lotissements ne sont pas à proprement parler des subdivisions. Je
verrais plutôt addr:sector=* ou addr:block=* (qui marcherais aussi au
Pérou avec les cuadras (pas sûr de l'orthographe), correspondant
plus ou moins aux ilôts, ou au Japon (les batiments sont numérotés
autour de l'ilôt, dans une seule séquence, même si on y accède par une
série de rues/routes). Cela marcherait aussi avec les résidences
privées en France. Ces noms de secteurs restent pertinents dans une
adresse complète, et c'est pour ça qu'on doit pouvoir les mettre dans
un tag addr:*=.

Pour les relations associatedStreet, cela devrait marcher même si le
même de rôle street n'est pas une rue linéaire mais un
bloc/ilôt/secteur/... polygonal.

D'ailleurs je me demande si ton lotissement en question n'est pas en
fait un lotissement privé (une copropriété), autrement dit une même
résidence, ce qui expliquerait que la rue n'ait pas de nom dans le
cadastre ou pour la commune. C'est le lotisseur ou la copropriété qui
a décidé de numéroter ses batiments ainsi sans donner de nom
(peut-être aussi parce que pour y accéder on a une seule voie d'accès
depuis le réseau public, cette voie faisant alors une boucle interne.
Ce ne serait donc qu'une rue privée.

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

[OSM-talk-fr] [amusant][fun] la France dans la France

2013-03-20 Thread david crochet


Bonjour.

Un peu de plaisir dans ces différents fils de discussion.
Cela ressemble à du «Funny Google Earth Place », mais OSM peut le faire 
aussi
Histoire de monter que notre surface terrestre ou les activités de 
l'Homme fabriquent des originalités :


http://tile.openstreetmap.fr/?zoom=18lat=48.77649lon=1.96174layers=B0

Bon amusement à trouver d'autre;

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

2013-03-20 Thread Francescu GAROBY

Tiens, la Corse serait-elle récemment devenue indépendante ? ;-)

Francescu


Le 20 mars 2013 09:45, david crochet david.croc...@online.fr a écrit :

 Bonjour.

 Un peu de plaisir dans ces différents fils de discussion.
 Cela ressemble à du «Funny Google Earth Place », mais OSM peut le faire
 aussi
 Histoire de monter que notre surface terrestre ou les activités de l'Homme
 fabriquent des originalités :

 http://tile.openstreetmap.fr/?**zoom=18lat=48.77649lon=1.**
 96174layers=B0http://tile.openstreetmap.fr/?zoom=18lat=48.77649lon=1.96174layers=B0

 Bon amusement à trouver d'autre;

 Cordialement

 --
 David Crochet

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr




-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

2013-03-20 Thread François


Le 20/03/2013 09:45, david crochet a écrit :


http://tile.openstreetmap.fr/?zoom=18lat=48.77649lon=1.96174layers=B0


Ils ont rasé la pointe du Raz 

--
François


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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

Le 20 mars 2013 09:48, Francescu GAROBY windu...@gmail.com a écrit :
 Tiens, la Corse serait-elle récemment devenue indépendante ? ;-)

Non elle ne tiendrait pas dans la carte. De même la Mer
Méditerranée ou l'océan Atlantique ne tiendraient pas tout entier dans
ce parc.

Noter la largeur du Rhône qui devient presque une mer, mais ne
semble pas avoir de liaison avec la Méditerranée.

En tout cas le nom des objets pourrait aussi causer des surprises dans
Nominatim (comme aussi les noms des îles artificielles du Monde aux
Emirats Arabes, où on pourrait voir apparaître aussi Paris, en
France, et en Europe).

Comme quoi on ne doit pas se contenter de lire les détails à moitié et
s'arrêter au premier nom d'objet trouvé.

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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

2013-03-20 Thread Christian Quest

Le 20 mars 2013 10:04, Philippe Verdy verd...@wanadoo.fr a écrit :
 En tout cas le nom des objets pourrait aussi causer des surprises dans
 Nominatim (comme aussi les noms des îles artificielles du Monde aux
 Emirats Arabes, où on pourrait voir apparaître aussi Paris, en
 France, et en Europe).


Je me suis posé la question... et lorsque l'on cherche Océan
Atlantique, Nominatim ne sort celui-ci qu'en 7ème position:
http://nominatim.openstreetmap.org/search.php?q=oc%C3%A9an+atlantique

Le vrai (place=ocean) ne sort qu'en 5ème position...

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

2013-03-20 Thread Nicolas Moyroud

Et hop chemins piétons ajoutés dans le parc ainsi que le stade de 
France miniature. J'en ai profité pour ajouter aussi des terrains de 
sport dans le stade juste à côté.
Juste au dessus du parc France miniature il y a un gros bazar avec une 
piste cyclable + un chemin piéton qui sont fait en 2 ways alors qu'a 
priori c'est le même. Pas le courage de corriger, si quelqu'un veut s'en 
charger... ;-)


Nicolas


Le 20/03/2013 09:45, david crochet a écrit :

Bonjour.

Un peu de plaisir dans ces différents fils de discussion.
Cela ressemble à du «Funny Google Earth Place », mais OSM peut le 
faire aussi
Histoire de monter que notre surface terrestre ou les activités de 
l'Homme fabriquent des originalités :


http://tile.openstreetmap.fr/?zoom=18lat=48.77649lon=1.96174layers=B0 



Bon amusement à trouver d'autre;

Cordialement




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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

C'est parce qu'il y a plein de noeuds place définis localement autour
des océans, très certainement pour le rendu...
Mais Nominatim ne peut pas faire la différence entre eux, il classe en
premier les noeuds place avant les régions fermées. Mais est-ce que
l'océan est fermé ? Où est le mieux placé le noeud pour l'océan ???

Ici il affiche en premier les noeuds qui sont inclus dans la
définition territoriale d'une autre région (ici
Terre-Neuve-et-Labrador) parce que cela apporte plus de précision que
le noeud isolé au milieu de l'océan.

On pourrait refaire le même test avec la Méditerranée (dont
l'essentiel de la surface est inclus dans les limites territoriales ou
les ZEE des pays limitrophes). Ou avec les noms locaux de mers ou de
baies et golfes donnés à certaines parties de la Méditerranée
(l'Adriatique, le Golfe de Gêne, la Mer Égée, etc...)

Le 20 mars 2013 10:52, Christian Quest cqu...@openstreetmap.fr a écrit :
 Le 20 mars 2013 10:04, Philippe Verdy verd...@wanadoo.fr a écrit :
 En tout cas le nom des objets pourrait aussi causer des surprises dans
 Nominatim (comme aussi les noms des îles artificielles du Monde aux
 Emirats Arabes, où on pourrait voir apparaître aussi Paris, en
 France, et en Europe).


 Je me suis posé la question... et lorsque l'on cherche Océan
 Atlantique, Nominatim ne sort celui-ci qu'en 7ème position:
 http://nominatim.openstreetmap.org/search.php?q=oc%C3%A9an+atlantique

 Le vrai (place=ocean) ne sort qu'en 5ème position...

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

Re: [OSM-talk-fr] [amusant][fun] la France dans la France

Le 20 mars 2013 10:52, Christian Quest cqu...@openstreetmap.fr a écrit :
 Le vrai (place=ocean) ne sort qu'en 5ème position...

Tout cela pose la question de la pertinence des noeuds place pour les
océans. On est dans le cas où ce devrait être plutôt une région
polygonale.

Mais cela pose aussi la question des frontières floues : OK les
lignes de côte sont à peu près bien définies, mais les séparations
entre les océans ne le sont pas.

On n'a aucun système de tag actuellement permettant de marquer qu'un
chemin utilisé comme frontoère d'une relation multipolygone est en
fait une frontière floue, avec une tolérance indiquée en terme de
distance (en mètres) pour établir une zone buffer sur leur
incertitude. La seule chose qu'on peut faire c'est se faire superposer
partiellement les polygones sur leur zone d'incertitude.

Ces cas existent aussi pour les frontières de pays :
- entre les Emirats arabes par exemple, leur limite étant une ligne
incertaine au milieu du désert, et dont la souveraineté n'est pas
clairement établie.
- entre les ZEE de nombreux pays (faute de traités ratifiés ou de
réglement de leur litige devant une cour internationale pour le droit
marin)

Bref pour l'instant il faut accepter que des zones se superposent
partiellement, on ne peut alors pas faire de conflation sur une ligne
unique. mais même dans ce cas, pour éviter des éditions et reverts
mutliples (revendications nationales) on pourrait indiquer que les
deux lignes tracées de chaque cpoté de la zone buffer sont
insertaines. Il faudrait donc de toute façon un tag pour ça (et
probablement aussi une note=*)

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

2013-03-20 Thread Vincent Pottier


Le 20/03/2013 09:11, Christian Quest a écrit :

Le 20 mars 2013 08:54, Vincent Pottier vpott...@gmail.com a écrit :

Pourquoi faut-il ajouter gare dans le nom alors qu'il y a railway=station
C'est comme porter une ceinture et des bretelles.
Si l’algorithme ne s'y retrouve pas c'est l’algorithme qu'il faut changer.

Il n'est pas toujours possible de calculer ces noms automatiquement et
surtout sans faire d'erreur.

Gare de
Gare du
Gare d'

Gérer correctement les H aspirés ou muets est une galère...

Le diable se cache dans les détails... et les exceptions ;)


Alors pour chasser le diable, je préférerais un alt_name=Gare d'Ambialet
Je peux en causer à un exorciste... J'en ai un à la maison :-)

http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only

N.B. La question se pose aussi pour d'autres objets...
Je tagge les églises en name=Église Saint-Glinglin|Collégiale 
Sainte-Gudule|Abbatiale Saint Propter... et ai un peu standardisé cette 
forme (en évitant la redondance église abbatiale).
Église, Collégiale, Abbatiale, Basilique, Cathédrale sont des titres 
comme Docteur, Professeur donc font tout de même partie du nom (En droit 
canonique chapelle est un titre un peu différent, mais bon... on reste 
simple).
On peut considérer les Collège École primaire... un peu de la même 
façon s'il sont apposés au nom auxquels ces établissements sont 
dédicacés : Collège Paul-Émile Victor


Mais Église de Truc-les-Nemours, ce n'est pas un name... Ni Mairie de 
Truc-les-Nemours, ni Stade de Truc-les-Nemours, ni Gare de 
Truc-les-Nemours, ni Collège de Truc-les-Nemours.
Et encore moins les formes toutes sèches Église, Mairie, Stade, 
Gare, Collège... Pas bien !

--
FrViPofm

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

2013-03-20 Thread Pieren

2013/3/20 Romain MEHUT romain.me...@gmail.com:

 Il existe aussi http://wiki.openstreetmap.org/wiki/Key:addr:place et sur la
 liste il y a déjà eu une discussion à ce sujet avec aussi un addr:hamlet

Ici, on est dans le cas d'une résidence, pas d'un hameau

Je me souviens d'une discussion un peu similaire sur la liste tagging:
http://gis.19327.n5.nabble.com/Block-names-vs-street-names-in-Brasilia-tt5660694.html

On parlait de créer un tag place=block (ou neighbourhood à mettre
sur le polygone landuse) ou un autre du genre addr:block. Mais quand
on regarde dans les statistiques de taginfo, cela n'a pas eu beaucoup
de succès (et ça n'est pas documenté).
Perso, je conserverais le schéma présenté au début avec
addr:housenumber + addr:street et je laisserais les validateurs
couiner. Peut-être qu'un tag note devrait expliquer brièvement la
solution adoptée en attendant mieux (et éviter que d'autres ne cassent
tout sans comprendre ce qui se passe). Avec ces tags, nominatim
devrait s'en sortir.

Pieren

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

Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence

En attendant, on pouvait chercher tous les arrondissements français
par leur nom simple, et c'était bien dans la liste des résultats
retournés par Nominatim.

Mais si maintenant on recherche Cognac, on ne troue plus QUE la
ville et pas l'arrondissement, et c'est... mal.

Le fait que la liste retournée par Nominatim quand on cherche juste
Cognac contienne AUSSI l'arrondissement n'est PAS une anomalie de
Nominatim.

On peut uniquement jouer sur le critère de pertinence pour que la
ville soit listée avant l'arrondissement dans cette liste, et les
moyens pour ça existent déjà. Mais il n'y a strictement aucune raison
de supprimer l'arrondissement de cette liste par le renommage.

Le critère de pertinence est forcément subjectif et dépendant de ce
que recherche l'utilisateur, ce n'est pas à nous de décider que la
ville doit y figurer mais pas l'arrondissement. Mais on peut faire en
sorte que la ville apparaisse en premier sans utiliser ce renommage.

Bref il faut revenir à Cognac pour le name=*.

Les autres considérations comme le fait de composer l'expression
arrondissement de Cognac à partir des infos déjà corrects fournies
sont du traitement linguistique, et cela n'a rien à voir avec ce que
doit contenir et retourner une base de données lors des recherches,
car elle fournit déjà assez d'infos.

On pourrait éventuellement codifier et taguer les traitements
linguistiques possibles, mais si on veut on peut toujours ajouter un
autre tag pour la forme longue. Mais même si on a mis un tag
supplémentaire long_name=Arrondissement de Cognac, il restera encore
le problème de la capitale initiale (malvenue pour l'utilisation dans
une phrase car le mot Arrondissement n'est pas un nom propre) et du
fait qu'il faudra éventuellement contracter un article placé avant
avec une apostrophe (bref cela demanderait encore un traitement
linguistique, spécifique au français, avec sa propre codification de
toute façon si on devait la renseigner aussi dans la base).

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

En revanche addr:place=* a beaucoup de succès (en Russie
essentiellement). Et cela résout le problème très bien chez eux pour
leurs adresses.

Bref créer une relation polygone pour le lotissement, mettre un
place=* dessus, et utiliser cette relation dans les relations
associatedStreet si on utilise cette méthode.

Pour les maisons individuelles, si on ne veut taguer qu'un noeud,
addr:house_number=* et addr:place=* conviendra très bien. Et pas
besoin que addr:house_number=* soit obligatoirement tagué avec
addr:street=* sur le même objet (addr:place=* est suffisant et le
remplace).

Le 20 mars 2013 12:16, Pieren pier...@gmail.com a écrit :
 2013/3/20 Romain MEHUT romain.me...@gmail.com:

 Il existe aussi http://wiki.openstreetmap.org/wiki/Key:addr:place et sur la
 liste il y a déjà eu une discussion à ce sujet avec aussi un addr:hamlet

 Ici, on est dans le cas d'une résidence, pas d'un hameau

 Je me souviens d'une discussion un peu similaire sur la liste tagging:
 http://gis.19327.n5.nabble.com/Block-names-vs-street-names-in-Brasilia-tt5660694.html

 On parlait de créer un tag place=block (ou neighbourhood à mettre
 sur le polygone landuse) ou un autre du genre addr:block. Mais quand
 on regarde dans les statistiques de taginfo, cela n'a pas eu beaucoup
 de succès (et ça n'est pas documenté).
 Perso, je conserverais le schéma présenté au début avec
 addr:housenumber + addr:street et je laisserais les validateurs
 couiner. Peut-être qu'un tag note devrait expliquer brièvement la
 solution adoptée en attendant mieux (et éviter que d'autres ne cassent
 tout sans comprendre ce qui se passe). Avec ces tags, nominatim
 devrait s'en sortir.

 Pieren

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

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

2013-03-20 Thread Christian Rogel


Je ne vois pas le problème qu'il y a à mettre le nom du lotissement comme nom 
des rues.
C'est, encore une fois, couper les cheveux en quatre et prendre Le Pirée pour 
un homme.
Cela figure comme adresse dans les documents officiels et tout le reste est 
littérature.

Au moins, on évite de se prendre la tête avec des place.
Les deux peuvent coexister, mais, c'est plus urgent d'avoir un système 
cohérent, en France, pour les adresses.

Au final, ce n'est guère différent d'avoir un mettre nom de rue pour un très 
vaste lotissement.
http://www.openstreetmap.org/?lat=47.9864077270031lon=-4.071577191352844zoom=18

Et c'est efficace pour le routage.


Christian Rogel



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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

Justement non poour le routage, car un lotissement peut malgré tout
comprendre plusieurs routes ou chemins. Le routage cherchera le
highway le plus proche du point à atteindre, mais pour la
géolocalisation de l'adresse c'est autre chose et cela se base
beaucoup plus sur la recherche d'abord de surfaces englobantes pour
aboutir à soit un noeud soit une route, soit le plus petit polygone
approchant le point à atteindre.

Ce n'est donc pas du tout couper les cheveux en 4. Les place ne sont
pas des rues/routes/chemins/highway. Et c'est pourtant ce à quoi doit
être associé un champ d'adresse addr:street, indépendamment des autres
éléments d'adresse (la ville est une surface par exemple, comme le
pays; le numéro de maison est généralement porté sur un seul noeud
mais ce peut être parfois un petit polygine correspondant à un
bâtiment ou morceau de bâtiment)

Note bien que le logiciel de routage ne peut généralement PAS
atteindre le noeud porteur du tag addr:house-number car il n'est
généralement pas sur la route/rue mais à côté. On sait juste que ce
noeud est associé à la rue la plus proche de ce noeud.

Mais si ce n'est pas le cas, on a besoin de taguer addr:street=* ou
addr:place=* selon l'étendue qui a été numérotée, et ce n'est
certainement pas un highway dans le cas d'une rue anonyme où les
numéros sont associés à tout un lotissement/bloc/secteur et pour
lequel il faut un aute champ addr:place=*, les deux pouvant cependant
exister aussi de temps en temps, par exemple pour les adresses dans
les rues longeant une place, mot en français ici, où la numérotation
de la rue s'arrête temporairement et où les maisons autour de la place
ont leur propre numérotation circulaire (sans distinction
pair/impair).

Ca peut donc donner des adresses comme:
- 3 Place de l'Eglise, CP Ville (addr:house_number=3, addr:place=Place
de l'Eglise)
- Rue de la Libération, 3 place de l'Eglise, CP Ville (on a en plus
addr:street=Rue de la Libération, pas de numéro pour la rue de la
Libération, c'est celle de la place dans addr:place=... )

Il est enfin assez courant qu'une place publique ait une numérotation
circulaire, même si chacun de ses côté a un noim de rue différent. Si
on supprime le nom de la place et qu'on met seulement le nom de la
rue, l'adresse devient carrément... fausse ! Car ce numéro peut exiser
ailleurs dans la même rue mais PAS sur cette place.

Le 20 mars 2013 12:47, Christian Rogel
christian.ro...@club-internet.fr a écrit :

 Je ne vois pas le problème qu'il y a à mettre le nom du lotissement comme
 nom des rues.
 C'est, encore une fois, couper les cheveux en quatre et prendre Le Pirée
 pour un homme.
 Cela figure comme adresse dans les documents officiels et tout le reste est
 littérature.

 Au moins, on évite de se prendre la tête avec des place.
 Les deux peuvent coexister, mais, c'est plus urgent d'avoir un système
 cohérent, en France, pour les adresses.

 Au final, ce n'est guère différent d'avoir un mettre nom de rue pour un très
 vaste lotissement.
 http://www.openstreetmap.org/?lat=47.9864077270031lon=-4.071577191352844zoom=18

 Et c'est efficace pour le routage.


 Christian Rogel




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

[OSM-talk-fr] [forum-osm-fr] AGIR AVEC NOUS...STAGES ET CHANTIERS JEUNES A L'ETRANGER

2013-03-20 Thread forum

Le message suivant de :
##


Bonjour ,

JSA - Togo (Afrique) est une association de développement humain qui œuvre pour 
la cause des enfants, des jeunes et des communautés.

 *** Nous organisons des missions d'aide à l’éducation et à la santé tout au 
long de l'année au Togo:

- Construction de bibliothèque ou de salles de classe;

- Aide à la scolarisation en soutien d’un professeur dans une classe;

- Soutien Scolaire

- Animation socio - culturelle ( sport, jeux, cirque, chants , contes , 
danses)

- Éducation spécialisé dans nos centres d'éveil pour enfants

***et proposons également des stages conventionnés aux étudiants et aux 
professionnels

-  Soins Infirmiers, Psychologie, aide soignant

-  Éducateurs spécialisés,

- Communication ( Audiovisuel )

- Management de projets et autres stages...

 

 L'association a pour objectifs :

- aider à une éducation scolaire des enfants;

-soutenir les communautés à assurer leur propre développement;

- offrir des stages conventionnés (éducation, soins infirmiers, etc.);

- aider à la sensibilisation sur les IST / VIH SIDA;

- faire découvrir d’autres cultures et horizons;

- permettre d'acquérir une première expérience en vue de fait carrière dans 
l’humanitaire.



 Pensons Globalement,Agissons localement...



 Pour Participer à nos actions d'aide au développement(programme disponible sur 
le site), vous êtes porteur d'un projet ou vous voulez nous aider de quelques 
manières , veuillez nous contacter par :E - mail: jsat...@yahoo.fr  

Site www.jsatogo.org

 

NB : Nous accompagnons des groupes de personnes pour la recherche de 
financement pour le projet et le voyage.

JSA - TOGO







a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=6t=585
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleures réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum-liste
peuvent être posées à sylvainaletuffe.org

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

[OSM-talk-fr] Tsunami au Mt St Michel ???

2013-03-20 Thread Jo.

En regardant quelques exemple de carte, Mapnik m'a affiché le Mont St
Michel en partie sous les eaux. J'ai rafraîchi mon cache et cette fois ci
c'est tous le mont St Michel qui est sous les eaux.

Je croit avoir assisté au premier raz de marrée en direct sur OSM ;-)

Plus sérieusement, j'ai chargé la zone dans JOSM et je n'ai pas vu de
modification particulière. Je refile la patate chaude à celui qui arrivera
à comprendre.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] récupération lignes et polygones sur Qgis

2013-03-20 Thread Stephane_geom

Bonjour,

J'ai rajouté des données via JOSM il y a environ 2 semaines et elles
apparaissent bien en ligne sur OSM.
http://www.openstreetmap.org/?lat=43.3647745lon=6.711835zoom=16
http://www.openstreetmap.org/?lat=43.3647745lon=6.711835zoom=16  

Aujourd'hui j'ai besoin de les récupérer sur Qgis (par l'intermédiaire d'un
fichier zone.osm extrait de Josm et du plugin osm pour Qgis) mais le
problème c'est que je n'ai que des points!!
Pourquoi les polygones et les polylignes ne se construisent pas sur Qgis??

J'ai essayé avec d'autres lieu et ca fonctionnent parfaitement...

Quelqu'un a une idée?
Merci



-
Stéphane ROLLE
Géomaticien - Consultant SIG


--
View this message in context: 
http://gis.19327.n5.nabble.com/recuperation-lignes-et-polygones-sur-Qgis-tp5754025.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] osm2psql, problème de fichier.

2013-03-20 Thread sly (sylvain letuffe)

On mercredi 20 mars 2013, Vincent Pottier wrote:
 Merci pour vos conseils.

Je suggère de passer sur la liste dev-fr (en copie de ce mail)

peux-tu renvoyer :
$ osm2pgsql -h

et le full log de ta tentative d'import
Peux tu tenter avec un fichier .osm.bz2 tout petit (genre corse.osm.bz2) ?


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-talk-fr] récupération lignes et polygones sur Qgis

2013-03-20 Thread Pieren

2013/3/20 Stephane_geom rolle.steph...@gmail.com:

 Aujourd'hui j'ai besoin de les récupérer sur Qgis (par l'intermédiaire d'un
 fichier zone.osm extrait de Josm et du plugin osm pour Qgis) mais le
 problème c'est que je n'ai que des points!!
 Pourquoi les polygones et les polylignes ne se construisent pas sur Qgis??

 J'ai essayé avec d'autres lieu et ca fonctionnent parfaitement...

 Quelqu'un a une idée?

Peut-être est-ce lié aux osm-ids qui doivent maintenant être en 64
bits, ce que ne fait pas encore le plugin osm pour qgis (déjà
mentionné sur cette liste). En attendant le correctif, on peut
contourner le problème en convertissant les données osm en shapefiles
par exemple.

Pieren

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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage

2013-03-20 Thread Tony Emery

Christian Rogel wrote
 Je ne vois pas le problème qu'il y a à mettre le nom du lotissement comme
 nom des rues.
 C'est, encore une fois, couper les cheveux en quatre et prendre Le Pirée
 pour un homme.
 Cela figure comme adresse dans les documents officiels et tout le reste
 est littérature.
 
 Au moins, on évite de se prendre la tête avec des place.
 Les deux peuvent coexister, mais, c'est plus urgent d'avoir un système
 cohérent, en France, pour les adresses.
 
 Au final, ce n'est guère différent d'avoir un mettre nom de rue pour un
 très vaste lotissement.
 http://www.openstreetmap.org/?lat=47.9864077270031lon=-4.071577191352844zoom=18
 
 Et c'est efficace pour le routage.
 
 Christian Rogel

Je suis désolé mais le nom d'un lotissement n'est pas une adresse mais un
complément d'adresse.
On a bien : 9, rue des Lilas, Lotissement des fleurs, 84100 Orange
ou : 113 Avenue du Général de Gaulle, 84100 Orange
et on a : (lot) 12, lotissement du Moulin, 84100 Orange
et nous, on a même : impasse 21 Rue Alexis Carrel, 84100 Orange

si on met sur la voie name=lotissement du Moulin dans le troisième cas, on
met quoi pour le premier :
- name=rue des Lilas, Lotissement des fleurs (c'est pas génial)
- name=rue des Lilas (du coup on perd l'info du lotissement)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Rues-sans-nom-dans-les-lotissements-et-adressage-tp5753877p5754031.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] double-frontière dans le Pas-de-Calais

2013-03-20 Thread Francescu GAROBY

Bonjour,
Le Pas-de-Calais a 2 frontières maritimes : une provenant du
cadastrehttp://www.openstreetmap.org/browse/way/132283075,
et utilisée par une commune, un canton, une circonscription législatives et
une communauté de communes, l'autre (de type coastline)
http://www.openstreetmap.org/browse/way/38118290ayant pour source PGS
(?), et utilisée par les communes, arrondissements, départements et région.

Les ways que je cite ont chacune des petites sœurs de part et d'autre (les
2 frontières étant découpées en 3-4 morceaux). Et ce problème est assez
récurrent, y a-t-il une règle d'harmonisation dans ces cas-là ?

-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] double-frontière dans le Pas-de-Calais

2013-03-20 Thread sly (sylvain letuffe)

On mercredi 20 mars 2013, Francescu GAROBY wrote:
  y a-t-il une règle d'harmonisation dans ces cas-là ?

http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Les_limites_administratives_c.C3.B4ti.C3.A8res

Cependant, ce consensus n'est pas partagé par tout le monde. Bien que j'ai 
quand même l'impression qu'il a la préférence de la majorité.

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-talk-fr] récupération lignes et polygones sur Qgis

2013-03-20 Thread Nicolas Moyroud



Le 20/03/2013 15:12, Pieren a écrit :


Peut-être est-ce lié aux osm-ids qui doivent maintenant être en 64
bits, ce que ne fait pas encore le plugin osm pour qgis (déjà
mentionné sur cette liste). En attendant le correctif, on peut
contourner le problème en convertissant les données osm en shapefiles
par exemple.

Pieren


Bonjour Pieren,

Quelle solution utilises-tu pour convertir les données osm en shapefiles 
? Personnellement j'utilise QGIS, mais du coup ce serait un peu le 
serpent qui se mord la queue...
Je pense notamment à une solution qui puisse faire cette conversion sans 
interface graphique pour pouvoir la scripter. Si tu as des infos, je 
suis intéressé.


Nicolas


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

Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage