date:20130509

Am 9. Mai 2013 03:22 schrieb Christian Müller cmu...@gmx.de:

 Am 09.05.2013 00:55, schrieb Ruben Kelevra:
  Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des
  Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet
  gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen
  soll. Das ist das primäre Problem.
 
  Hat jemand dafür einen Vorschlag?

 Vorschlag:  Schaue Dir die administrativen Stadt-/Ortsteilgrenzen von
 anderen Städten, wie z.B. Berlin oder Hamburg an.



nur geht es ja nicht nur um administrative Grenzen sondern auch um
Siedlungsgeografie, gerade z.B. in Großstädten wie Berlin und Hamburg, die
nicht direkt vergleichbar sind mit einer Kleinstadt, wird das besonders
deutlich.

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

Re: [Talk-de] Spendenkampagne 2013 der OSMF für neue Hardware

Frederik Ramm frede...@remote.org wrote:

Ich hoffe nicht, dass es bei uns zu einem Wikipedia-Effekt kommt und 
Euch irgendwann um die Adventszeit das Antlitz unseres Vorsitzenden (so 
fotogen, wie Simon auch sein mag!) von jeder OSM-Webseite entgegenlacht 
mit einem Spendenaufruf.

Ich finde solch eine Spendenaktion (auch für OSM) in Ordnung, weil sie
sich nicht an die Aktiven sondern vornehmlich an die Nutzer/Leser
wendet. Dass die Spenden auch aus diesem Bereich kommen, lässt sich an
den zahlreichen Spendenkommentaren ablesen. Es ist übrigens
interessant, darin zu stöbern, weil man als Aktiver manche der
Verwendungen niemals auf dem Schirm gehabt hätte. 

Die Zahl derjenigen, die proforma einen Euro spenden, um hier eine
Kritik anzubringen, liegt gefühlt im Subpromillebereich. Insgesamt
lässt sich resümieren, dass die Nutzer wirklich gerne spenden und froh
sind, auf diese Möglichkeit aufmerksam gemacht worden zu sein.

Und auch OSM hat ja schon davon profitiert, unter Anderem durch die
Initiative von Marc. OSM wird bei Wikimedia Deutschland inzischen
bezüglich der finanziellen Förderung mit Wikipedia gleichgestellt.
OSMler sollten daher IMHO bei Bedarf diese Finanzquelle häufiger
nutzen. Das hierfür abgestellte Budget wird unter dem Aspekt der
Förderung freier Projekte und Software verteilt.

Durch diese Spenden ist man beispielsweise auch bei den offiziell
angesetzten Konferenzen nicht mehr auf Sponsoren angewiesen. Das gilt
auch für die Räumlichkeiten. Womit nicht gesagt sei, dass man auf
diese Sponsoren verzichten sollte. Denn dies erzeugt zumindest in
Teilen auch einen Solidarisierungseffekt.

Den Wikipedia Effekt, den ich als viel schlimmer empfinde, ist das
Entwickeln des Eigenlebens unter der Angestelltenschaft sowohl der
weltweiten Foundation als auch des deutschen Vereins. Da muss sich die
Community jetzt Dinge erwehren, die sie nicht gutheißt. Da aber die
Community nur nebenberuflich arbeitet, kann sie mitunter nicht gegen
die Vollzeitler anstinken, die zudem eine bessere finanzielle
Ausstattung haben und insgesamt am längeren Hebel sitzen. Das ist IMHO
eine klare Schwächung und Demotivation für die Community.

Das ist eine Entwicklung, die ich mir für OSM nicht wünsche.

Nichtsdestotrotz finde ich es eine gute Idee, DEN Kernserver des
Projektes durch die Aktiven zu finanzieren. Das Bewusstsein, das
Projekt aus eigener Kraft am Laufen halten zu können, schafft
sicherlich auch einen Solidarisierungseffekt.
 
Nebenebei bemerkt ist es inzwischen nicht nur Jimmy Wales (nicht mehr
Vorsitzender, sondern nur noch Gründer) sondern ein Konglomerat von
Wikipedia/Wikimedia bezogenen Personen, mit deren Konterfei dort
geworben wird. Übrigens: Man kann den Aufruf übrigens auch dauerhaft
abschalten.


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

Re: [Talk-de] Stadtteilfuckup in Nominatim

2013-05-09 Per discussione fly

On 09.05.2013 00:22, Martin Koppenhoefer wrote:

 sind das nodes oder Flächen? Flächen sind weil sie explizit das Gebiet
 definieren besser als nodes, bei Nodes kann Nominatim (und jeder andere)
 nur raten, wie groß das Gebiet ist. Ggf. kannst Du das hierarchisieren,
 indem Du das auf place=suburb und place=neighbourhood aufteilst.

Frage mich ja ob Nominatim mit place nodes in boundary relationen
umgehen kann.

Wobei place ja auch recht schwierig sein kann. Kenne hier ein
Neubaugebiet (Quatier), das sich auf beiden Seiten einer admin=6 Grenze
befindet.

cu
fly

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

Re: [Talk-de] Stadtteilfuckup in Nominatim





On 09/mag/2013, at 15:57, fly lowfligh...@googlemail.com wrote:

 Frage mich ja ob Nominatim mit place nodes in boundary relationen
 umgehen kann.

M.E. ist das nicht unbedingt nötig bzw. sinnvoll, da es orthogonale 
Eigenschaften sind (solange wir von boundary=administrative reden), ein 
namematching bzw. räumliche Abfragen kann man ja auch so machen. 

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

[Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
dieses Problem IMHO jetzt nochmals. 

Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
Meinung über die Sicherheitsmaßnahmen in Editoren gegen
unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
Meinungen auseinander. Daher bitte ich um Drittmeinungen: 

In ID ist es durch die umringenden Icons jetzt für Anfänger noch
einfacher als in Potlatch, versehentlich etwas zu löschen oder die
Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
abzufahren?

Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
Teilstückes. Auch hier: Es kostet große Mühen, eine lange
Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
entsprechende Fehlermeldungen nicht zumuten kann. 

So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
Quadratkilometer die einzigen dauerhaften Mapper sind.


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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione fly

On 09.05.2013 16:17, Tirkon wrote:

Ersteinmal Danke für den neuen Editor.

 Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
 Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
 willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
 dieses Problem IMHO jetzt nochmals. 
 
 Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
 Meinung über die Sicherheitsmaßnahmen in Editoren gegen
 unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
 Meinungen auseinander. Daher bitte ich um Drittmeinungen: 
 
 In ID ist es durch die umringenden Icons jetzt für Anfänger noch
 einfacher als in Potlatch, versehentlich etwas zu löschen oder die
 Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
 und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
 durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
 wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
 um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
 dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
 für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
 abzufahren?
 
 Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
 Teilstückes. Auch hier: Es kostet große Mühen, eine lange
 Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
 bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
 kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
 wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
 entsprechende Fehlermeldungen nicht zumuten kann. 
 
 So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
 verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
 Quadratkilometer die einzigen dauerhaften Mapper sind.

+10

Ich warte auch schon lange auf Änderungen in potlatch(2), wenn jetzt
auch noch iD mit ähnlichen Problemen auftaucht ist das um so frustrierender.

Bitte keine Veränderung von Objekten ohne Korrektes Verhalten in Bezug
auf Relationen.

Dies gilt vorallem für Löschen und Richtungsänderungen aber auch
Aufteilen ist problematisch.

Im Zweifelsfall braucht man halt doch einen anständigen
Relationseditor oder man darf solche Operation nicht erlauben.

Grüße
fly

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Peter Wendorff

Hi.

Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder
niemand - dich eingeschlossen - hat es als Fehler erkannt und den
Entwicklern mitgeteilt.

Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht:

https://github.com/systemed/iD/issues/1458

Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal
gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine
Auswertung darüber fährt (in Changesets erkennen, wenn die
node-reihenfolge eines Weges umgekehrt worden ist).

Was Relationen angeht:
Multipolygone werden direkt unterstützt - allerdings gibt es keinen
Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die
Fläche klicken.
Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch
noch nicht ausprobiert.

Gruß

Peter

Am 09.05.2013 16:17, schrieb Tirkon:
 Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
 Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
 willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
 dieses Problem IMHO jetzt nochmals. 
 
 Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
 Meinung über die Sicherheitsmaßnahmen in Editoren gegen
 unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
 Meinungen auseinander. Daher bitte ich um Drittmeinungen: 
 
 In ID ist es durch die umringenden Icons jetzt für Anfänger noch
 einfacher als in Potlatch, versehentlich etwas zu löschen oder die
 Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
 und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
 durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
 wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
 um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
 dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
 für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
 abzufahren?
 
 Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
 Teilstückes. Auch hier: Es kostet große Mühen, eine lange
 Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
 bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
 kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
 wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
 entsprechende Fehlermeldungen nicht zumuten kann. 
 
 So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
 verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
 Quadratkilometer die einzigen dauerhaften Mapper sind.
 
 
 ___
 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] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Simon Poole

Es gibt dazu schon einen uraltes Ticket von mir
https://github.com/systemed/iD/issues/299

Das Problem war und ist also bekannt.

Simon

Am 09.05.2013 16:58, schrieb Peter Wendorff:
 Hi.

 Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder
 niemand - dich eingeschlossen - hat es als Fehler erkannt und den
 Entwicklern mitgeteilt.

 Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht:

 https://github.com/systemed/iD/issues/1458

 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal
 gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine
 Auswertung darüber fährt (in Changesets erkennen, wenn die
 node-reihenfolge eines Weges umgekehrt worden ist).

 Was Relationen angeht:
 Multipolygone werden direkt unterstützt - allerdings gibt es keinen
 Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die
 Fläche klicken.
 Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch
 noch nicht ausprobiert.

 Gruß

 Peter

 Am 09.05.2013 16:17, schrieb Tirkon:
 Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
 Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
 willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
 dieses Problem IMHO jetzt nochmals. 

 Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
 Meinung über die Sicherheitsmaßnahmen in Editoren gegen
 unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
 Meinungen auseinander. Daher bitte ich um Drittmeinungen: 

 In ID ist es durch die umringenden Icons jetzt für Anfänger noch
 einfacher als in Potlatch, versehentlich etwas zu löschen oder die
 Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
 und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
 durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
 wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
 um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
 dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
 für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
 abzufahren?

 Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
 Teilstückes. Auch hier: Es kostet große Mühen, eine lange
 Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
 bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
 kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
 wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
 entsprechende Fehlermeldungen nicht zumuten kann. 

 So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
 verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
 Quadratkilometer die einzigen dauerhaften Mapper sind.


 ___
 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



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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Alex Barth

Tirkon oder Simon -

Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das
Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder
es handelt sich hier einfach um ein anderes Problem.

Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen.

Danke!



2013/5/9 Simon Poole si...@poole.ch

 Es gibt dazu schon einen uraltes Ticket von mir
 https://github.com/systemed/iD/issues/299

 Das Problem war und ist also bekannt.

 Simon

 Am 09.05.2013 16:58, schrieb Peter Wendorff:
  Hi.
 
  Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder
  niemand - dich eingeschlossen - hat es als Fehler erkannt und den
  Entwicklern mitgeteilt.
 
  Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht:
 
  https://github.com/systemed/iD/issues/1458
 
  Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal
  gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine
  Auswertung darüber fährt (in Changesets erkennen, wenn die
  node-reihenfolge eines Weges umgekehrt worden ist).
 
  Was Relationen angeht:
  Multipolygone werden direkt unterstützt - allerdings gibt es keinen
  Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die
  Fläche klicken.
  Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch
  noch nicht ausprobiert.
 
  Gruß
 
  Peter
 
  Am 09.05.2013 16:17, schrieb Tirkon:
  Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
  Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
  willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
  dieses Problem IMHO jetzt nochmals.
 
  Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
  Meinung über die Sicherheitsmaßnahmen in Editoren gegen
  unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
  Meinungen auseinander. Daher bitte ich um Drittmeinungen:
 
  In ID ist es durch die umringenden Icons jetzt für Anfänger noch
  einfacher als in Potlatch, versehentlich etwas zu löschen oder die
  Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
  und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
  durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
  wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
  um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
  dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
  für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
  abzufahren?
 
  Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
  Teilstückes. Auch hier: Es kostet große Mühen, eine lange
  Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
  bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
  kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
  wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
  entsprechende Fehlermeldungen nicht zumuten kann.
 
  So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
  verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
  Quadratkilometer die einzigen dauerhaften Mapper sind.
 
 
  ___
  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



 ___
 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] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Simon Poole


Ich hatte es damals mit ein paar Beispielen getestet und es schien OK,
hab jetzt mal 1.0.0 mit cycleway:right getestet, iD ändert das korrekt
in cycleway:left um.

Die grundsätzliche Funktionalität scheint also da zu sein, vielleicht
kann tirkon sonst ein Beispiel liefern das nicht wie erwartet tut.

Simon

 
Am 09.05.2013 17:28, schrieb Alex Barth:
 Tirkon oder Simon -

 Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das
 Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder
 es handelt sich hier einfach um ein anderes Problem.

 Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen.

 Danke!



 2013/5/9 Simon Poole si...@poole.ch

 Es gibt dazu schon einen uraltes Ticket von mir
 https://github.com/systemed/iD/issues/299

 Das Problem war und ist also bekannt.

 Simon

 Am 09.05.2013 16:58, schrieb Peter Wendorff:
 Hi.

 Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder
 niemand - dich eingeschlossen - hat es als Fehler erkannt und den
 Entwicklern mitgeteilt.

 Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht:

 https://github.com/systemed/iD/issues/1458

 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal
 gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine
 Auswertung darüber fährt (in Changesets erkennen, wenn die
 node-reihenfolge eines Weges umgekehrt worden ist).

 Was Relationen angeht:
 Multipolygone werden direkt unterstützt - allerdings gibt es keinen
 Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die
 Fläche klicken.
 Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch
 noch nicht ausprobiert.

 Gruß

 Peter

 Am 09.05.2013 16:17, schrieb Tirkon:
 Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
 Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
 willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
 dieses Problem IMHO jetzt nochmals.

 Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
 Meinung über die Sicherheitsmaßnahmen in Editoren gegen
 unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
 Meinungen auseinander. Daher bitte ich um Drittmeinungen:

 In ID ist es durch die umringenden Icons jetzt für Anfänger noch
 einfacher als in Potlatch, versehentlich etwas zu löschen oder die
 Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
 und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
 durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
 wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
 um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
 dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
 für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
 abzufahren?

 Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
 Teilstückes. Auch hier: Es kostet große Mühen, eine lange
 Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
 bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
 kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
 wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
 entsprechende Fehlermeldungen nicht zumuten kann.

 So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
 verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
 Quadratkilometer die einzigen dauerhaften Mapper sind.


 ___
 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


 ___
 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



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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Jo

Ich habe auch mal versucht ein Memberway der zu 2 route Relationen gehört
zu löschen und das ist tatsäglich möglich, und sogar ohne Botschaft das
etwas kaputgemacht wird.

Dann auch mal mit PL2 versucht und der macht dasselbe

Unglaublich. Sowas kann ich nicht verstehen.

Polyglot

2013/5/9 Alex Barth a...@mapbox.com

 Tirkon oder Simon -

 Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das
 Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder
 es handelt sich hier einfach um ein anderes Problem.

 Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen.

 Danke!



 2013/5/9 Simon Poole si...@poole.ch

  Es gibt dazu schon einen uraltes Ticket von mir
  https://github.com/systemed/iD/issues/299
 
  Das Problem war und ist also bekannt.
 
  Simon
 
  Am 09.05.2013 16:58, schrieb Peter Wendorff:
   Hi.
  
   Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder
   niemand - dich eingeschlossen - hat es als Fehler erkannt und den
   Entwicklern mitgeteilt.
  
   Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht:
  
   https://github.com/systemed/iD/issues/1458
  
   Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal
   gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine
   Auswertung darüber fährt (in Changesets erkennen, wenn die
   node-reihenfolge eines Weges umgekehrt worden ist).
  
   Was Relationen angeht:
   Multipolygone werden direkt unterstützt - allerdings gibt es keinen
   Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die
   Fläche klicken.
   Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch
   noch nicht ausprobiert.
  
   Gruß
  
   Peter
  
   Am 09.05.2013 16:17, schrieb Tirkon:
   Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von
   Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens
   willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft
   dieses Problem IMHO jetzt nochmals.
  
   Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die
   Meinung über die Sicherheitsmaßnahmen in Editoren gegen
   unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die
   Meinungen auseinander. Daher bitte ich um Drittmeinungen:
  
   In ID ist es durch die umringenden Icons jetzt für Anfänger noch
   einfacher als in Potlatch, versehentlich etwas zu löschen oder die
   Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
   und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur
   durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche
   wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich,
   um ein kilometerweites Netz abzufahren und maxspeed detailliert zu
   dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg
   für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut
   abzufahren?
  
   Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
   Teilstückes. Auch hier: Es kostet große Mühen, eine lange
   Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu
   bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick
   kommentarlos zerstört. Auch diese Fehler sind für Andere kaum
   wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern
   entsprechende Fehlermeldungen nicht zumuten kann.
  
   So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches
   verschrieben haben - insbesondere dann, wenn sie auf mehrere zig
   Quadratkilometer die einzigen dauerhaften Mapper sind.
  
  
   ___
   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
 
 
 
  ___
  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

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Wilhelm Spickermann

Hi,

Am Thu, 9 May 2013 17:52:36 +0200
schrieb Jo winfi...@gmail.com:

 Ich habe auch mal versucht ein Memberway der zu 2 route Relationen
 gehört zu löschen und das ist tatsäglich möglich, und sogar ohne
 Botschaft das etwas kaputgemacht wird.
 
 Dann auch mal mit PL2 versucht und der macht dasselbe

Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in
der Realität ein Loch ... darüber könnte man noch diskutieren.
Klar wäre der Fall, wenn es nach dem Löschen eines Weges z.B.
zweielementige Abbiegerelationen gäbe.

Wilhelm

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

Re: [Talk-de] Stadtteilfuckup in Nominatim

2013-05-09 Per discussione Georg Feddern


Moin,

Am 09.05.2013 00:55, schrieb Ruben Kelevra:

Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des
Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet
gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen
soll. Das ist das primäre Problem.

Hat jemand dafür einen Vorschlag?


Ich kenne keine Gemeinde/Stadt, die aus Ortsteilen/Stadtteilen besteht, 
wo das Kerngebiet nicht auch ein Ortsteil/Stadtteil ist.
Also wird es wohl auch dort für den 'Stadtkern' eine administrative 
Struktur samt Namen geben - ich tippe mal auf Wermelskirchen. ;-)



Den Rest werde ich mal so probieren wie hier vorgeschlagen, entweder
ein Shape oder nur die Straße selbst taggen.


Shape / Grenze - selbst in geschätzter Lage - ist der bessere Weg.
Selbst ein place-Node 'Stadtkern' hilft nicht weiter, wenn halt der 
äußere Stadtteil-Node immer noch dichter dran liegt ...


Gruß
Georg


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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Vielen Dank für Eure Reaktionen. Damit ist einer der Punkte erledigt.
Im Einzelnen:

Tirkon tirko...@yahoo.de wrote:

In ID ist es durch die umringenden Icons jetzt für Anfänger noch
einfacher als in Potlatch, versehentlich etwas zu löschen 

Die Kritik an den nahen gefährlichen Icons bleibt nach den
bisherigen Rückmeldungen bestehen. Ich sehe da nur die Alternative,
sie an weniger exponierter Stelle anzuordnen.

oder die
Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward
und backward Angaben. 

Das kann als erledigt angesehen werden. Offenbar werden hieraus
resultierende Restfehler bei Eintrag in die Bugliste berücksichtigt.

Auch bei Relationen kommt keinerlei Warnung bei Löschen eines
Teilstückes.

Hier scheint es den Reaktionen nach tatsächlich noch Nachholbedarf zu
geben. Es muss noch einmal tiefergehend recherchiert werden, ob
Relationen neben dem Löschen von Teilstücken auch durch andere
Aktionen ohne Warnung zerstört werden.

Zudem wurde hier noch das Splitting genannt. Wo da genau das Problem
mit ID bzw. Potlatch liegt, habe ich allerdings noch nicht ergründet.

Möglicherweise wäre eine Kontaktaufnahme der ID-Programmierer mit
denen von JOSM sinnvoll. Denn Letztere haben die Juckelpunkte um
Relationen schon erkannt und behoben bzw. sprechen entsprechende
Warnungen aus.


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

[Talk-de] OSM Stand auf der FROSCON

2013-05-09 Per discussione Sven Geggus

Hallo zusammen,

ich war im letzen Jahr zum ersten mal auf der FROSCON um einen
Vortrag über OSM Daten in PostGIS zu halten.

Da mir die Konferenz recht gut gefallen hat (eigentlich so wie
Linuxtag ganz früher) fand ich es etwas schade, dass OSM nicht
wirklich vertreten war.

Ich wäre bereit, das in diesem Jahr zu ändern und suche Mitstreiter
für den Aufbau eines OSM Standes.

Wenn sich noch 2-3 Leute bei mir melden würde ich einen Stand
beantragen.

Gruss

Sven

-- 
If you can spend five minutes on the Internet and do not run Linux,
you're a genius. (Dirk Hohndel)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Wilhelm Spickermann o...@spickermann-d.de wrote:

Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in
der Realität ein Loch ... darüber könnte man noch diskutieren.

Häufig wird nicht deswegen gelöscht, weil etwas nicht mehr existiert,
sondern beispielsweise eine Kreuzung auf die in der Realität
existierende Richtungsfahrbahntrennung umgestellt wird. Es gibt viele
Beispiele, wo das Bearbeiten durch Löschen eines Weges stattfinden
kann, wo es eigentlich nicht erforderlich wäre. Es stört aber auch
nicht, solange man Ortskenntnis hat und keine Relationen beteiligt
sind. Anfänger löschen auch mal gerne einen ganzen Straßenzug, um ihn
dann korrigiert neu zu erstellen. Dass dabei die Historie zum Teufel
geht, ist wohl ein notwendiges Übel, eine Relationszerstörung hingegen
nicht.

Ohne Warnung vor Relationszerstörung kommt der Bearbeitende und
insbesondere der Anfänger nicht auf die Idee, sich um andere Methoden
des Editierens zu bemühen, die ein Löschen eines Weges nicht
erfordern. Ohne Warnung kommt er nicht auf die Idee, dass da etwas
nach Abschluss des beabsichtigten Editierens zu reparieren wäre. 

Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört.
Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen
wurde. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und
fand mich in der Historie als Verursacher von weiteren gefundenen
Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu
zukünftig nicht mehr zwingend erforderlich wäre.


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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Ruben Kelevra

Ich sehe das ähnlich wie du, keiner der zerstörerischen Änderungen die ich
je korrigiert hab wurde mit JOSM erstellt.

Lg Ruben
Am 10.05.2013 00:14 schrieb Tirkon tirko...@yahoo.de:

 Wilhelm Spickermann o...@spickermann-d.de wrote:

 Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in
 der Realität ein Loch ... darüber könnte man noch diskutieren.

 Häufig wird nicht deswegen gelöscht, weil etwas nicht mehr existiert,
 sondern beispielsweise eine Kreuzung auf die in der Realität
 existierende Richtungsfahrbahntrennung umgestellt wird. Es gibt viele
 Beispiele, wo das Bearbeiten durch Löschen eines Weges stattfinden
 kann, wo es eigentlich nicht erforderlich wäre. Es stört aber auch
 nicht, solange man Ortskenntnis hat und keine Relationen beteiligt
 sind. Anfänger löschen auch mal gerne einen ganzen Straßenzug, um ihn
 dann korrigiert neu zu erstellen. Dass dabei die Historie zum Teufel
 geht, ist wohl ein notwendiges Übel, eine Relationszerstörung hingegen
 nicht.

 Ohne Warnung vor Relationszerstörung kommt der Bearbeitende und
 insbesondere der Anfänger nicht auf die Idee, sich um andere Methoden
 des Editierens zu bemühen, die ein Löschen eines Weges nicht
 erfordern. Ohne Warnung kommt er nicht auf die Idee, dass da etwas
 nach Abschluss des beabsichtigten Editierens zu reparieren wäre.

 Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört.
 Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen
 wurde. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und
 fand mich in der Historie als Verursacher von weiteren gefundenen
 Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu
 zukünftig nicht mehr zwingend erforderlich wäre.


 ___
 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] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Wilhelm Spickermann

Hi,

Am Thu, 09 May 2013 23:12:36 +0200
schrieb Tirkon tirko...@yahoo.de:

 Zudem wurde hier noch das Splitting genannt. Wo da genau das Problem
 mit ID bzw. Potlatch liegt, habe ich allerdings noch nicht ergründet.
 
 Möglicherweise wäre eine Kontaktaufnahme der ID-Programmierer mit
 denen von JOSM sinnvoll. Denn Letztere haben die Juckelpunkte um
 Relationen schon erkannt und behoben bzw. sprechen entsprechende
 Warnungen aus.

Es gibt mehrere Splittingprobleme und man findet sie teilweise auch im
JOSM.

Ein im JOSM m.W. gelöstes Splittingproblem gibt es bei den
Abbiegerelationen. Nur einer der beiden Teile des aufgeteilten Weges
sollte in der Relation bleiben.

Ein weiteres Splittingproblem haben wir bei den Relationen mit
bedeutungsvoller Reihenfolge, also z.B. bei Routen nach dem Public
Traffic Proposal. Hier wird die Durchfahrtrichtung nicht mit forward
oder backward oder  (=bidirektional) angegeben, sondern durch die
Reihenfolge der Mitglieder in jeder Variante. Hier tritt z.B. in der
einen Relation die Wegreihenfolge A,B,C auf und in einer anderen C,B,A.
Spaltet man B auf, dann kann man es nicht einfach überall durch B1,B2
ersetzen, denn wenn A,B1,B2,C richtig ist, dann ist C,B1,B2,A falsch.
Da muss dann C,B2,B1,A hin. Das macht der Potlatch falsch und der JOSM
macht es nur dann richtig, wenn er die Elemente A und/oder C geladen
hat. (Gewöhnt man sich als JOSM-Benutzer an, vor dem Splitten immer
eine beliebig kleine Umgebung der Endpunkte des zu splittenden Weges zu
laden, dann gibt es keine Probleme.)

Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein
Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil
des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese
Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und
die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle
anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter
splitten und bei allen nachkorrigieren. Das unterstützt keiner der
Editoren. (Ich halte es meist für Quatsch Kreisverkehre zu splitten,
aber es gibt andere Ansichten/Situationen und wenn man da splittet,
dann gibt es dieses Problem.)

Wilhelm

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

2013-05-09 Per discussione Wilhelm Spickermann

Hi,

Am Fri, 10 May 2013 07:08:32 +0200
schrieb Wilhelm Spickermann o...@spickermann-d.de:

 Ein drittes Splittingproblem...


Ich hab noch eines vergessen:

Ein viertes Splittingproblem haben wir bei in sich geschlossenen Wegen
mit einem Flächentag. Wenn man hier hier aufspaltet, braucht man ein
Multipolygon. Da unterstützt m.W. kein Editor.

Wilhelm

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

Re: [Talk-it] Albergo diffuso

2013/5/9 Jeawrong jeawithl...@tin.it

 Non mastico ancora bene le relazioni, a quel che vedo [1] le relazioni di
 tipo site sono fra le features proposte, ma non mi è ben chiaro come
 utilizzarle, per ora ho creato la relazione

 type=site
 name=BB dei Serafini




+1, non è molto chiaro come utilizzare le relazioni site. Se si può,
utilizzerei relazioni del tipo multipoligono, e solo nel caso che devi:

1. aggiungere nodi

2. specificare ruoli particolari

utilizzerei la relazione site. Per il resto va bene anche un multipoligono.

Nonostante ci sono 130.000+ relazioni site nel database, credo che nessuno
le valuta.


che al momento comprende la reception con ruolo entrance (e su questo nodo
 ho inserito tutte le info del BB, indirizzo, sito web, email, telefono,
 ecc. ecc.)



il ruolo entrance sarebbe un requisito per utilizzare un site, ma credo
che dovrebbe poi essere un ingresso, mentre la reception non vedo come
ingresso in questo senso.


ciao,
Martin

PS: http://wiki.openstreetmap.org/wiki/Relation:site
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site


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

Re: [Talk-it] spostamento pagina wiki.

2013-05-09 Per discussione Alberto Nogaro

-Original Message-
From: girarsi_liste [mailto:liste.gira...@gmail.com]
Sent: mercoledì 8 maggio 2013 17:00
To: talk-it@openstreetmap.org
Subject: Re: [Talk-it] spostamento pagina wiki.

Ok, grazie, attendo ancora qualche osservazione per la pagina poi
procederò.

La pagina che hai creato contiene parecchie informazioni e spunti utili, ma
differisce molto dall'equivalente inglese, e a mio parere forse cerca di
raccogliere troppe indicazioni su una stessa pagina. Anche per uniformità,
ritengo che sarebbe meglio cominciare con una semplice traduzione delle
pagine per cui ancora non esiste la traduzione in italiano. Salvo situazioni
particolari che si applicano solo all'Italia, eventuali integrazioni
sarebbero poi da aggiungere anche alla pagina inglese. Purtroppo il tema è
parecchio intricato e difficile da raccogliere su un'unica pagina, e si
rischia di dare indicazioni che contraddicono altre pagine.  Per questo
procederei a piccoli passi.

Secondo me sarebbe preferibile cominciare a tradurre dall'inglese le pagine
per cui ancora manca la versione italiana, come:

http://wiki.openstreetmap.org/wiki/Key:footway
http://wiki.openstreetmap.org/wiki/Key:sidewalk
http://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing (aggiornamento)
http://wiki.openstreetmap.org/wiki/Crossing
http://wiki.openstreetmap.org/wiki/Path_controversy

Ciao,
Alberto

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

Re: [Talk-it] spostamento pagina wiki.

2013/5/9 Alberto Nogaro bartosom...@yahoo.it

  Anche per uniformità,
 ritengo che sarebbe meglio cominciare con una semplice traduzione delle
 pagine




+1, è fondamentale che le traduzioni sono, appunto, solo traduzioni. Se si
intende di variare o estendere il contenuto dovrebbe essere fatto sulla
pagina inglese e poi successivamente sulle pagine tradotte.

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

Re: [Talk-it] spostamento pagina wiki.


Il 09/05/2013 09:53, Alberto Nogaro ha scritto:

Secondo me sarebbe preferibile cominciare a tradurre dall'inglese le pagine
per cui ancora manca la versione italiana, come:

http://wiki.openstreetmap.org/wiki/Key:footway
http://wiki.openstreetmap.org/wiki/Key:sidewalk
http://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing (aggiornamento)
http://wiki.openstreetmap.org/wiki/Crossing
http://wiki.openstreetmap.org/wiki/Path_controversy

Ciao,
Alberto


Grazie per l'osservazione.

Ammesso e concesso, da quanto ho visto, pure alcune versioni inglesi 
sono, diciamo così, da rivedere, non solo per le definizioni, resta il 
problema che sarebbe preferibile io l'inglese lo sapessi, ma da queste 
parti il mio cervello è arido di termini anglosassoni, salvo quelli di 
moda..


Di conseguenza ho tre strade, o mi affido al motore di traduzione, 
tenuto conto dei nomi dei tag, e rimetto a ci lo sà il controllo 
traduzione, oppure, cerco di imparare l'inglese, e forse prima della 
pensione (innominabile ormai) ci riesco.. oppure mi limito a 
cercare di migliorare quelle italiane, però cè il problema che troppe 
modifiche alle pagine della  wiki non fanno bene al sistema stesso.


Cè pure la quarta soluzione, cioè questa in mailing list, cerco di avere 
più osservazioni possibili, come la tua, per poter trarre e trasmettere 
nella pagina la definizione migliore possibile, perchè poi deve restare, 
almeno come punto di riferimento fisso, senza mettere in dubbio il fatto 
che le pagine sono tante e chi traduce è sempre in numero molto 
inferiore al bisogno, e bisognerà comunque tener conto pure dei niubbi, 
questi sono il futuro per tante cose, pure per la wiki.


Quindi ancora, sono un pò impacciato lo so, però voglio contribuire, si 
tratta di vedere la soluzione migliore per farlo, e capirsi insomma.

--
Simone G.

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

Re: [Talk-it] spostamento pagina wiki.

2013/5/9 girarsi_liste liste.gira...@gmail.com

 Il 09/05/2013 09:53, Alberto Nogaro ha scritto:

  Secondo me sarebbe preferibile cominciare a tradurre dall'inglese le
 pagine
 per cui ancora manca la versione italiana, come:

 http://wiki.openstreetmap.org/**wiki/Key:footwayhttp://wiki.openstreetmap.org/wiki/Key:footway
 http://wiki.openstreetmap.org/**wiki/Key:sidewalkhttp://wiki.openstreetmap.org/wiki/Key:sidewalk
 http://wiki.openstreetmap.org/**wiki/Tag:footway%3Dcrossinghttp://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing(aggiornamento)
 http://wiki.openstreetmap.org/**wiki/Crossinghttp://wiki.openstreetmap.org/wiki/Crossing
 http://wiki.openstreetmap.org/**wiki/Path_controversyhttp://wiki.openstreetmap.org/wiki/Path_controversy




 Ammesso e concesso, da quanto ho visto, pure alcune versioni inglesi sono,
 diciamo così, da rivedere, non solo per le definizioni,




si, occorre alle volte, anche se per le pagine sopraindicate sarebbe
strano, visto che parliamo proprio di key-features. Alle volte il problema
sono modifiche unilaterali che certi utenti applicano alle pagine del wiki,
e finchè qualcuno fa un undo (rimette a posto) si trovano informazioni
sbagliati. Se riscontri problemi del genere vale la pena segnalarli qui in
lista (o in inglese in lista tagging).



 resta il problema che sarebbe preferibile io l'inglese lo sapessi, ma da
 queste parti il mio cervello è arido di termini anglosassoni, salvo quelli
 di moda..


 Di conseguenza ho tre strade, o mi affido al motore di traduzione,




non te lo consiglio, sono dettagli troppo particolari e fini per essere
tradotti senza giudizio umano.



 tenuto conto dei nomi dei tag, e rimetto a ci lo sà il controllo
 traduzione, oppure, cerco di imparare l'inglese, e forse prima della
 pensione (innominabile ormai) ci riesco.. oppure mi limito a
 cercare di migliorare quelle italiane, però cè il problema che troppe
 modifiche alle pagine della  wiki non fanno bene al sistema stesso.



si, in linea di base vorremo che la versione ufficiale è quella inglese e
che tutte le altre pagine in lingua sono solo traduzioni, perché altrimenti
si rischia fortemente di usare gli stessi tags per cose diverse (cosa in
certi limiti è anche inevitabile, visto che ci sono differenze culturali).




 Cè pure la quarta soluzione, cioè questa in mailing list, cerco di avere
 più osservazioni possibili, come la tua, per poter trarre e trasmettere
 nella pagina la definizione migliore possibile, perchè poi deve restare,
 almeno come punto di riferimento fisso, senza mettere in dubbio il fatto
 che le pagine sono tante e chi traduce è sempre in numero molto inferiore
 al bisogno, e bisognerà comunque tener conto pure dei niubbi, questi sono
 il futuro per tante cose, pure per la wiki.



si, l'utilità delle traduzioni in lingua è innegabile, ed è un vero lavoro
da Sisifo, visto che le pagine cambiano sempre ;-)

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

Re: [Talk-it] spostamento pagina wiki.


Il 09/05/2013 11:33, Martin Koppenhoefer ha scritto:

Quindi, ribaltando tutto il discorso, prendendo spunto dalla tua 
risposta, se la mia pagina, una volta sistemata và meglio di quella 
inglese, nulla toglie di sistemare quella inglese?


tenuto conto dell'internazionalizzazione del contenuto, perchè sennò, se 
guardiamo all'Inghilterra.. Dio ce ne salvi dalla pasta con 
marmellata. O_o..

--
Simone G.

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

Re: [Talk-it] Caricare info/node OSM direttamente su OpenLayers.

2013-05-09 Per discussione pjhooker

Sono riuscito a completare il cerchio
- parse del JSON per i nodi di OSM in un determinato BOX
- visualizzazione di solo quelli che hanno il tag wikipedia
- mappa openlayers con geometry.point
- popup con link all'articolo di Wikipedia e immagine nel tag image deln
nodo

ecco il risultato: http://host.logosloci.com/cityplanner/index.php/92

adesso posso divertirmi a mappare OSM e linkare Wikipedia ...

*ps. questione in sospeso: nell'articolo di Wikipedia, c'è un modo adeguato
per inserire il link al suo  corrispettivo elemento di OSM?*
http://gis.19327.n5.nabble.com/file/n5760315/wiki_plus_osm.png 



--
View this message in context: 
http://gis.19327.n5.nabble.com/Caricare-info-node-OSM-direttamente-su-OpenLayers-tp5759882p5760315.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] spostamento pagina wiki.

2013/5/9 girarsi_liste liste.gira...@gmail.com

 Quindi, ribaltando tutto il discorso, prendendo spunto dalla tua risposta,
 se la mia pagina, una volta sistemata và meglio di quella inglese, nulla
 toglie di sistemare quella inglese?



diciamo che farei al contrario, cambiando prima quella inglese, però in
teoria si. In pratica è molto difficile di trovare un accordo tra la
comunità internazionale per cambiare pagine di features principali (come
highway). Lo farei solo previa discussione sulla lista tagging, ovviamente.



 tenuto conto dell'internazionalizzazione del contenuto, perchè sennò, se
 guardiamo all'Inghilterra.. Dio ce ne salvi dalla pasta con
 marmellata. O_o.



non guardiamo molto all'Inghilterra, per lo più sono i tedeschi attivi,
anche se non funziona ne anche il loro approccio (non di tutti, ma di
tanti) di pensare che in tutto il mondo le cose sono come in Germania ;-).
Purtroppo anche i tedeschi fanno la stessa cosa che scrivono alle volte
anziché traduzioni delle pagine inglesi, delle pagine modificate in tedesco
oppure inventano proprio pagine in tedesco che non esistono in altre
lingue. Capisco perché, ma credo che rende più difficile di tenere uniformo
il sistema di tagging al livello internazionale.

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

[Talk-it] aggiornamento dati gfoos ancora ko?

2013-05-09 Per discussione beppebo...@libero.it

sistema aggiornamento dati gfoos.

Il sistema di aggiornamento dati gfoos è così irrimediabilmente ancora 
danneggiato o è stata sostituita la pagina in altro link e mi è sfuggito 
qualcosa? Sembrava fosse una  cosa da poco:(

Confido in voi:)

Ciao

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

Re: [Talk-it] come mappo un terreno non coperto da vegetazione

2013-05-09 Per discussione Aury88

non credo sia adatto come tag, il terreno non è roccioso, è solo terra (prato
calpestato)



--
View this message in context: 
http://gis.19327.n5.nabble.com/come-mappo-un-terreno-non-coperto-da-vegetazione-tp5760095p5760354.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] come mappo un terreno non coperto da vegetazione


Il 09/05/2013 17:06, Aury88 ha scritto:

non credo sia adatto come tag, il terreno non � roccioso, � solo terra (prato
calpestato)



--
View this message in context: 
http://gis.19327.n5.nabble.com/come-mappo-un-terreno-non-coperto-da-vegetazione-tp5760095p5760354.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



forse:

landcover=bare_heart
surface=grass

--
Simone G.

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

Re: [Talk-it] spostamento pagina wiki.

Ho modificato la parte in cima della pagina cercando di tradurla ed 
adattarla, spero di non aver travisato troppo. qualcuno può controllare?
ripeto, solo la parte in cima, la tabella penso sia comoda anche nella 
pagina inglese fatta la debita, si spera degna, traduzione, oppure 
bisogna chiedere alla lista internazionale per questo?


QUella tradotta italiana:

http://wiki.openstreetmap.org/wiki/User:Simone_girardelli/Sandbox/IT:Tag:highway%3Dfootway

La rispettiva inglese:

http://wiki.openstreetmap.org/wiki/User:Simone_girardelli/Sandbox/IT:Tag:highway%3Dfootway


Il wikilink per wikiedia italiana non ho capito come farlo per il 
termine marciapiede, per ora ho messo il link nascosto nel testo, poi 
magari se qualcuno m'insegna, glie ne sarei grato, perchè nelle varie 
guide di markup, non ho trovato ciò che cercavo, ed i modi proposti non 
funzionavano, o indirizzavano a quella inglese.


--
Simone G.

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

[Talk-se] Mapwarper

2013-05-09 Per discussione Lars Aronsson


På adressen http://mapwarper.net/maps/1283#Preview_Map_tab
har jag laddat upp en del av Generalstabskartan från 1875
och anpasst den till rätt koordinater. Med ett reglage kan
växla gradvis mellan OSM-kartan och den inscannade.

Om ni skaffar ett konto och loggar in, kan ni redigera
kartan också, t.ex. lägga till fler kontrollpunkter.

Prova gärna att ladda upp någon inscannad karta, kanske från
http://commons.wikimedia.org/wiki/Category:Generalstabskartan_s%C3%B6dra_1880


--
  Lars Aronsson (l...@aronsson.se)
  Aronsson Datateknik - http://aronsson.se

  Wikimedia Sverige - stöd fri kunskap - http://wikimedia.se/

  Projekt Runeberg - fri nordisk litteratur - http://runeberg.org/
  Följ Projekt Runeberg på https://www.facebook.com/ProjektRuneberg



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

Re: [Talk-es] Trabajo de Importación de la Red de Autobuses de Córdoba

2013-05-09 Per discussione Patricio Soriano

Adjunto remito texto de solicitud (12 de marzo de 2013) de datos a Aucorsa,
sociedad anónima municipal que gestiona la red de transporte público de
Córdoba (Anexo I) por Pedro Pérez y la respuesta obtenida por parte del
responsable del Área de Tecnología de Aucorsa

Anexo I

De: Pedro Perez Martin [mailto:pedrope...@gmail.com] 
Enviado el: martes, 12 de marzo de 2013 10:06
Para: Luis Fernando Arcos Serrano; Carlos Sierra Martín-Serrano
Asunto: Solicitud uso datos Aucorsa en OSM
 
Carlos Sierra Martín-Serrano
Director-Gerente de Autobuses de Córdoba, S.A.M. (Aucorsa)
Luis Fernando Arcos Serrano 
Responsable área de Tecnología de Aucorsa
 
Estimados Carlos y Luis Fernando,

Participamos en un proyecto, desarrollado a través de Internet, llamado
OpenStreetMap.org[1], en adelante OSM. La idea es crear un mapa que esté
disponible libremente y que pueda ser utilizado por todo el mundo, al estilo
de la Wikipedia. El mapa de OSM dispone, además, de una capa especializada
en mostrar las líneas de transporte público.

Nos gustarías preguntarles si podemos utilizar los datos de lineas y paradas
preferentes, que hay en su sitio web[2], para mostrarlos sobre el mapa. Hay
que decir que los datos incorporados a OSM son liberados bajo una Licencia
Abierta para Bases de Datos (ODbL)[3], lo que significa que, todo el mundo
puede compartir (es decir, copiar, distribuir y usar para cualquier
propósito) los datos, crear nuevos trabajos a partir de los datos, y
adaptar, modificar, transformar y construir sobre esos datos, pero indicando
su procedencia, liberando los datos derivados bajo esa misma licencia, y
manteniendo los datos abiertos y accesibles para todo el mundo. La licencia
ODbL es equivalente a la licencia Creative Commons Atribución-Compartir bajo
la misma licencia que usa el proyecto Wikipedia[4], sólo que es específica
para datos. En otras palabras, se utilizarían sus datos junto con los ya
existentes en un gran proyecto conjunto que les agrega valor.

La inclusión de los datos de Aucorsa en OSM puede suponer una nueva
oportunidad de mejorar los servicios a los usuarios que ya ofrece la
empresa, pero antes necesitamos su autorización pues la política de OSM es
que debemos ser cuidadosos al obtener permiso para incorporar datos ajenos
en la base de datos. El mapa de OSM ya cuenta con información de algunas
paradas y lineas registradas por voluntarios, pero sin duda, con su
colaboración, lograríamos enriquecer el mapa mucho más.

Atentamente,
Pedro Pérez Martín, colaborador del proyecto OSM.

[1] http://www.openstreepmap.org/
[2] http://www.aucorsa.es/
[3] http://opendatacommons.org/licenses/odbl/summary/
[4] http://creativecommons.org/licenses/by-sa/2.0/es/

Anexo II

El 12 de abril de 2013 15:04, Luis Fernando Arcos Serrano
luisfernando.ar...@aucorsa.com escribió:

Buenas tardes Pedro,
 
Autobuses de Córdoba, S.A.M. (AUCORSA) acepta la participación en el
Proyecto de Integración de la capa de Transporte Público de Córdoba en OSM
(OpenStreetMaps).
 
Para ello, AUCORSA facilitará el archivo feed GTFS (General Transit Feed
Specification), que usa para representar la información de transporte
público sobre Google Maps. Este archivo contiene datos de las líneas,
recorridos, paradas, horarios y calendarios de los servicios de AUCORSA.
 
AUCORSA cede únicamente este archivo para este propósito y bajo los términos
y condiciones que establezca ODbL (Licencia Abierta para Bases de Datos).
 
Atentamente,
 

 
Luis Fernando Arcos Serrano
Responsable del Área de Tecnología
T: 957 764 241
F: 957 764 199
e-mail: luisfernando.ar...@aucorsa.com





--
View this message in context: 
http://gis.19327.n5.nabble.com/Trabajo-de-Importacion-de-la-Red-de-Autobuses-de-Cordoba-tp5759963p5760287.html
Sent from the Spain mailing list archive at Nabble.com.

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

Re: [Talk-es] discordancia entre Garmin y OSM

2013-05-09 Per discussione Javier Fernández Arroyo

Hola,

siento decir que me he instalado los mapas de hoy, y la locución sigue siendo 
la misma

Es decir, no ha sido corregido 

¿alguien podría corroborarlo?

gracias.

From: jfarroy...@hotmail.com
To: talk-es@openstreetmap.org
Date: Wed, 8 May 2013 16:35:48 +
Subject: Re: [Talk-es] discordancia entre Garmin y OSM




Estoy ahora mismo en el trabajo, esta noche cuando llegue a casa me descargo el 
fichero y vemos qué ocurre!! :)

Muchas gracias!

 Date: Wed, 8 May 2013 17:33:23 +0200
 From: cdavi...@orangecorreo.es
 To: talk-es@openstreetmap.org
 Subject: Re: [Talk-es] discordancia entre Garmin y OSM
 
 El 08/05/13 14:08, Jonas Andradas escribió:
 
  Perfecto,
 
  Yo los bajo del mismo sitio (¡gracias Carlos!), así que podré probar 
  también
 
  El 08/05/2013 13:09, Javier Fernández Arroyo jfarroy...@hotmail.com 
  mailto:jfarroy...@hotmail.com escribió:
 
  Hola de nuevo,
 
  Sí, es correcto lo que dices
 
  Los mapas OSM para Garmin los he sacado de esta página:
 
  http://mapas.alternativaslibres.es/descargas.php
 
  He usado el Archivo para copiar en el gps/navegador copiandolo
  directamente en una MicroSD
 
  Como la resolución es de hoy, hasta mañana por lo menos no podré
  averiguar si se ha corregido o no, ya que los mapas se actualizan
  una vez al día... sea lo que sea, por supuesto que lo comentaré :)
 
 Acabo de actualizar de nuevo los mapas de España, por si queréis probar
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
  

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

Re: [Talk-es] discordancia entre Garmin y OSM

2013-05-09 Per discussione Jonas Andradas

Yo probé con otro software ayer, y la ruta sí está bien. Voy a probar con
el Garmin, a ver qué dice...
El 09/05/2013 13:15, Javier Fernández Arroyo jfarroy...@hotmail.com
escribió:

 Hola,

 siento decir que me he instalado los mapas de hoy, y la locución sigue
 siendo la misma

 Es decir, no ha sido corregido

 ¿alguien podría corroborarlo?

 gracias.

 --
 From: jfarroy...@hotmail.com
 To: talk-es@openstreetmap.org
 Date: Wed, 8 May 2013 16:35:48 +
 Subject: Re: [Talk-es] discordancia entre Garmin y OSM

 Estoy ahora mismo en el trabajo, esta noche cuando llegue a casa me
 descargo el fichero y vemos qué ocurre!! :)

 Muchas gracias!

  Date: Wed, 8 May 2013 17:33:23 +0200
  From: cdavi...@orangecorreo.es
  To: talk-es@openstreetmap.org
  Subject: Re: [Talk-es] discordancia entre Garmin y OSM
 
  El 08/05/13 14:08, Jonas Andradas escribió:
  
   Perfecto,
  
   Yo los bajo del mismo sitio (¡gracias Carlos!), así que podré probar
   también
  
   El 08/05/2013 13:09, Javier Fernández Arroyo jfarroy...@hotmail.com
   mailto:jfarroy...@hotmail.com escribió:
  
   Hola de nuevo,
  
   Sí, es correcto lo que dices
  
   Los mapas OSM para Garmin los he sacado de esta página:
  
   http://mapas.alternativaslibres.es/descargas.php
  
   He usado el Archivo para copiar en el gps/navegador copiandolo
   directamente en una MicroSD
  
   Como la resolución es de hoy, hasta mañana por lo menos no podré
   averiguar si se ha corregido o no, ya que los mapas se actualizan
   una vez al día... sea lo que sea, por supuesto que lo comentaré :)
  
  Acabo de actualizar de nuevo los mapas de España, por si queréis probar
 
  ___
  Talk-es mailing list
  Talk-es@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-es

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

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


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

Re: [Talk-es] discordancia entre Garmin y OSM

2013-05-09 Per discussione Hector

No habéis pensado que puede ser debido a la diferente forma en que 
pueden estar trazados los carriles en OSM y GARMIN. Si no hay 2 carriles 
indicados dificilmente te puedes quedar a la izquierda. Después de todo 
el navegador solo es un interprete de la base de datos, y puede que lo 
esté indicando como debe. La clave será saber como ha distribuido garmin 
esos carriles.
Por lo que he visto en Josm hay 1 solo carril continuamente. Quizá 
editando con 2 carriles y separándolos solo al final del desvío cabe la 
posibilidad de que cambie la locución, que se produce antes de llegar al 
los desvíos
De todas formas los mapas Garmin siguen unos patrones que no conocemos 
totalmente a la hora de editar nosotros. Siempre puede haber 
discordancias. Este es nuestro reto. Haciendo pruebas  quiza encontremos 
el arreglo. aún así a dia de hoy, creo que el compilador de mapas OSM, 
tampoco sabe como mostrar el indicador de carriles ni como implementar 
el JCV. Eso ya sería al no va mas
Si alguien esta dispuesto a editar los carriles, lo comprobamos. Siempre 
se puede verificar con el modo simulación del GPS.

Un saludo a todos

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

Re: [Talk-es] discordancia entre Garmin y OSM

2013-05-09 Per discussione Javier Fernández Arroyo

 Siempre  se puede verificar con el modo simulación del GPS.
Un saludo a todos

eso es lo que hago jejejejeje

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

Re: [Talk-es] discordancia entre Garmin y OSM

2013-05-09 Per discussione Jonas Andradas

Buenas,

Pues no había caído en lo de los carriles. Es posible, y además en OSM hay
etiquetas para indicar que el carril de la izquierda es luego sólo para el
desvío de la izquierda, y cosas así.

En un rato actualizo la vía de salida con lanes=2
El 09/05/2013 18:45, Hector heutorecep...@ono.com escribió:

No habéis pensado que puede ser debido a la diferente forma en que pueden
estar trazados los carriles en OSM y GARMIN. Si no hay 2 carriles indicados
dificilmente te puedes quedar a la izquierda. Después de todo el navegador
solo es un interprete de la base de datos, y puede que lo esté indicando
como debe. La clave será saber como ha distribuido garmin esos carriles.
Por lo que he visto en Josm hay 1 solo carril continuamente. Quizá
editando con 2 carriles y separándolos solo al final del desvío cabe la
posibilidad de que cambie la locución, que se produce antes de llegar al
los desvíos
De todas formas los mapas Garmin siguen unos patrones que no conocemos
totalmente a la hora de editar nosotros. Siempre puede haber discordancias.
Este es nuestro reto. Haciendo pruebas quiza encontremos el arreglo. aún
así a dia de hoy, creo que el compilador de mapas OSM, tampoco sabe como
mostrar el indicador de carriles ni como implementar el JCV. Eso ya sería
al no va mas
Si alguien esta dispuesto a editar los carriles, lo comprobamos. Siempre
se puede verificar con el modo simulación del GPS.
Un saludo a todos

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

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

Re: [Talk-ro] Ce punem la name în cazul blocurilor?

2013-05-09 Per discussione Francisc TOTH



De obicei sunt sisteme de numerotatie diferite in adresa completa vopsita la 
itrarea in scara.


Daca adresa e de tipul : Strada Mimozei nr 17, Bloc B4, Sc A (are si scarile B, 
C, D) atunci (Strada Mimozei nr. 17) tine de numerotarea data de primarie, 
addr:street, addr:number, este suficient pentru identificarea unica a blocului 
respectiv. De ex. posta si firmele de curierat, taxi nu sunt interesati decat 
de strada si numar ca sa ajunga la adresa.


Numerotarea Bloc B4, B5, B17 este o numerotare data de sistemul de asociatii de 
locatari, cum erau inainte sau cum sunt si acum asociatii de proprietari, e un 
numar de ordine in catastifurile lor. Nu reflecta asezarea in spatiu a 
blocului, ci ordinea in care au fost luate in evidenta lor. Se poate sa avem 
blocuri de numite De la B1-B40 imprastiat pe 10 strazi, intr-o ordine 
neregulata. Personal nu as da valoare de adresa acestui cod intern pana la 
urma. Maxim name=B4 sau Bloc B4

In timp ce Strada si numarul nu se prea schimba, si cand se schimba este 
publicata, mai nou asociatiile de proprietari se agrega si se dezagrega, trec 
unele sub firme de hausmeiter si atunci se schimba numerotarile astea interne.





 From: Strainu strain...@gmail.com
To: Razvan radulescu.raz...@gmail.com 
Cc: OSM Romania talk-ro@openstreetmap.org 
Sent: Thursday, May 9, 2013 10:03 AM
Subject: Re: [Talk-ro] Ce punem la name în cazul blocurilor?
 

În data de 8 mai 2013, 20:07, Razvan radulescu.raz...@gmail.com a scris:


 In acest caz daca tot este trecut D3 pe bloc il lasam asa. Dar trebuie
 adaugat si numarul de adresa, adica Nr. 12 in acest caz deoarece mi se pare
 cel mai important pentru gasirea unei adrese la fix ( in cazul caselor). Si
 sa nu uitam de addr: street name. ca fara el numarul nu are nicio valoare.
 Nu este gasit la cautare in osmand.

Am reintrodus lista, scoasă din greșeala mea.

Sigur că pentru adresa completă e nevoie de tot ce ai zis tu, dar eu
vorbeam strict de câmpul name. Acolo în București e pus acel D3
(eventual cu Bl, bloc etc. în față). În alte părți e și altceva? Dacă
nu, poate putem rula scriptul lui Eddy pentru uniformizat numele și
pentru blocuri.

Strainu

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

Re: [Talk-ro] Ce punem la name în cazul blocurilor?

2013-05-09 Per discussione Strainu

În data de 9 mai 2013, 11:45, Francisc TOTH yo6...@yahoo.com a scris:

 De obicei sunt sisteme de numerotatie diferite in adresa completa vopsita
 la itrarea in scara.

 Daca adresa e de tipul : Strada Mimozei nr 17, Bloc B4, Sc A (are si scarile
 B, C, D) atunci (Strada Mimozei nr. 17) tine de numerotarea data de
 primarie, addr:street, addr:number, este suficient pentru identificarea
 unica a blocului respectiv. De ex. posta si firmele de curierat, taxi nu
 sunt interesati decat de strada si numar ca sa ajunga la adresa.

 Numerotarea Bloc B4, B5, B17 este o numerotare data de sistemul de asociatii
 de locatari, cum erau inainte sau cum sunt si acum asociatii de proprietari,
 e un numar de ordine in catastifurile lor. Nu reflecta asezarea in spatiu a
 blocului, ci ordinea in care au fost luate in evidenta lor. Se poate sa avem
 blocuri de numite De la B1-B40 imprastiat pe 10 strazi, intr-o ordine
 neregulata. Personal nu as da valoare de adresa acestui cod intern pana la
 urma. Maxim name=B4 sau Bloc B4

Asta era fix întrebarea pentru care am pornit threadul: name=B4 sau
name=Bloc B4? Restul sunt divagații, dar...


 In timp ce Strada si numarul nu se prea schimba, si cand se schimba este
 publicata, mai nou asociatiile de proprietari se agrega si se dezagrega,
 trec unele sub firme de hausmeiter si atunci se schimba numerotarile astea
 interne.

Eu n-am auzit să se schimbe numele/numerele de blocuri doar pentru că
s-a împărțit asociația...

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

[Talk-ro] Garmin

2013-05-09 Per discussione Lucian Popovici

Salut,

incerc sa pun harta Romaniei pe un Garmin Nuvi40 si am urmat tutorialul
acesta:
  http://www.cferrero.net/maps/garmin_maps_newbie_guide.html

Acum am harta dar funtia de cautare are probleme. Daca incerc sa cauta
orase cu B imi gaseste Bran sau Bucuresti. Aveti vreun sfat ?

-
Lucian Popovici
___
Talk-ro mailing list
Talk-ro@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

Re: [Talk-ro] Ce punem la name în cazul blocurilor?

2013-05-09 Per discussione Strainu

Dă te rog reply to all ca să rămână și lista în destinatari...

Marilor producători de hărți li se rupe de România. Dacă dau
București, Saidac Gheorghe nr X în hărțile de la Navteq o să mă
trimită pe Nucșoara. Iar în orașele mici degeaba știi tu că vrei să
ajungi pe Strada X, Nr Y, dacă întrebi pe cineva pe stradă habar n-o
să aibă. Dacă în schimb întrebi după nume, ai o șansă. De asta mi se
pare foarte important să ai și asemenea informați în OSM.

Strainu

În data de 9 mai 2013, 13:07, Razvan radulescu.raz...@gmail.com a scris:
 Marii producatori de harti ca Navteq sau tomtom sau TopMap  nu pun asa ceva
 pe harti. Ei pun doar numerele de adrese. La urma urmei cautarea unei adrese
 este dupa numele strazii si numar. Cum spunea si d-l Francisc Toth. Stiu
 asta deoarece acum 3 ani am colaborat cu cei de la TM aproape 1 an... Desi
 ar putea, nu isi permit asta din cauza lipsei de timp si de resurse umane
 pentru asa ceva. Ei folosec Mapinfo ca si program de editare  + ceva
 pluginuri personalizate facute de echipa lor de dezvoltare software.
  Unele dintre pluginuri sunt folosite inclusiv pentru exportarea din mapinfo
 a fisierului final cu extensia ceruta de programul de navigare specific. (
 de exemplu fbl in cazul Igo).


 On 09.05.2013 10:03, Strainu wrote:

 În data de 8 mai 2013, 20:07, Razvan radulescu.raz...@gmail.com a scris:


 In acest caz daca tot este trecut D3 pe bloc il lasam asa. Dar trebuie
 adaugat si numarul de adresa, adica Nr. 12 in acest caz deoarece mi se
 pare
 cel mai important pentru gasirea unei adrese la fix ( in cazul caselor).
 Si
 sa nu uitam de addr: street name. ca fara el numarul nu are nicio
 valoare.
 Nu este gasit la cautare in osmand.

 Am reintrodus lista, scoasă din greșeala mea.

 Sigur că pentru adresa completă e nevoie de tot ce ai zis tu, dar eu
 vorbeam strict de câmpul name. Acolo în București e pus acel D3
 (eventual cu Bl, bloc etc. în față). În alte părți e și altceva? Dacă
 nu, poate putem rula scriptul lui Eddy pentru uniformizat numele și
 pentru blocuri.

 Strainu



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

Re: [Talk-ro] Ce punem la name în cazul blocurilor?

2013-05-09 Per discussione Francisc TOTH

Buzau cumva? Parca acolo e asa :-)

Destul de complicat in acest caz, dar pana la urma addr: accepta orice string. 

 From: Cosmin Belea cbe...@gmail.com
To: OSM Romania talk-ro@openstreetmap.org 
Sent: Thursday, May 9, 2013 5:50 PM
Subject: Re: [Talk-ro] Ce punem la name în cazul blocurilor?

Si ce facem in cazurile in care exista o strada Libertatii numarul 1, apoi 
nenumarate blocuri? Stiu un caz concret in care un cartier intreg e la aceeasi 
adresa (strada / numar) dar cu numere de blocuri diferite.

2013/5/9 Francisc TOTH yo6...@yahoo.com

De obicei sunt sisteme de numerotatie diferite in adresa completa vopsita la 
itrarea in scara.

Daca adresa e de tipul : Strada Mimozei nr 17, Bloc B4, Sc A (are si scarile 
B, C, D) atunci (Strada Mimozei nr. 17) tine de numerotarea data de primarie, 
addr:street, addr:number, este suficient pentru identificarea unica a blocului 
respectiv. De ex. posta si firmele de curierat, taxi nu sunt interesati decat 
de strada si numar ca sa ajunga la adresa.

Numerotarea Bloc B4, B5, B17 este o numerotare data de sistemul de asociatii 
de locatari, cum erau inainte sau cum sunt si acum asociatii de proprietari, e 
un numar de ordine in catastifurile lor. Nu reflecta asezarea in spatiu a 
blocului, ci ordinea in care au fost luate in evidenta lor. Se poate sa avem 
blocuri de numite De la B1-B40 imprastiat pe 10 strazi, intr-o ordine 
neregulata. Personal nu as da valoare de adresa acestui cod intern pana la 
urma. Maxim name=B4 sau Bloc B4

In timp ce Strada si numarul nu se prea schimba, si cand se schimba este 
publicata, mai nou asociatiile de proprietari se agrega si se dezagrega, trec 
unele sub firme de hausmeiter si atunci se schimba numerotarile astea interne.

 From: Strainu strain...@gmail.com
To: Razvan radulescu.raz...@gmail.com 
Cc: OSM Romania talk-ro@openstreetmap.org 
Sent: Thursday, May 9, 2013 10:03 AM
Subject: Re: [Talk-ro] Ce punem la name în cazul blocurilor?

În data de 8 mai 2013, 20:07, Razvan radulescu.raz...@gmail.com a scris:

 In acest caz daca tot este trecut D3 pe bloc il lasam asa. Dar trebuie
 adaugat si numarul de adresa, adica Nr. 12 in acest caz deoarece mi se pare
 cel mai important pentru gasirea unei adrese la fix ( in cazul caselor). Si
 sa nu uitam de addr: street name. ca fara el numarul nu are nicio valoare.
 Nu este gasit la cautare in osmand.

Am reintrodus lista, scoasă din greșeala mea.

Sigur că pentru adresa completă e nevoie de tot ce ai zis tu, dar eu
vorbeam strict de câmpul name. Acolo în București e pus acel D3
(eventual cu Bl, bloc etc. în față). În alte părți e și altceva? Dacă
nu, poate putem rula
 scriptul lui Eddy pentru uniformizat numele și
pentru blocuri.

Strainu

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

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

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

Re: [Talk-cz] Preset pro JOSM

2013-05-09 Per discussione jzvc

Dne 9.5.2013 14:56, Václav Kubíček napsal(a):
 Ahoj, nevíte někdo jak vytvořit v JOSM předdefinovanou cestu (jestli to teda 
 jde)? Viz dotaz níže:

Cus, se obavam, ze toto nejde - preset = sestava tagu, ktery aplikujes
na node/way/... nevim o tom, ze by slo nadefinovat nejaky objekt. Asi by
to slo realizovat scriptem (pomoci pluginu), neznam moznosti, ale
predpokladam, ze by mohlo jit pridat odkaz v podobe ikony/polozky v
menu/hotkey.

BFUlike metoda by mohla byt, ze si proste nacmares jednotlivy typy,
ulozis si je jako OSM soubor a pak si to nactes jako samostatnou vrstvu,
ze ktery si vyberes, vlozis do mapovy vrstvy a nalezite otocis.


 ---
 Nevis jeste jak bych mohl v JOSM vyresit nasledujici problem?
 Kreslim ŘOPíky a snažím se je nakreslit tak, jak vypadají.
 Je mi jasný, že je to asi zbytečná blbost, ale libí se mi to.
 Treba tady
 http://www.openstreetmap.org/browse/way/220215769

 Jen se mi ty cesty blbe kopiruji. Nejde v JOSM si tu hotovou cestu
 ve tvaru bunkru model treba A120 v meritku nejak ulozit a pak ji
 rovnou pouzit jako nejaky Preset?

 Diky,

 Dalibor

 ---
 Vašek

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


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

Re: [Talk-cz] Preset pro JOSM

2013-05-09 Per discussione Petr Schönmann


On 9.5.2013 14:56, Václav Kubíček wrote:

Ahoj, nevíte někdo jak vytvořit v JOSM předdefinovanou cestu (jestli to teda 
jde)? Viz dotaz níže:

---
Nevis jeste jak bych mohl v JOSM vyresit nasledujici problem?
Kreslim ŘOPíky a snažím se je nakreslit tak, jak vypadají.
Je mi jasný, že je to asi zbytečná blbost, ale libí se mi to.
Treba tady
http://www.openstreetmap.org/browse/way/220215769

Jen se mi ty cesty blbe kopiruji. Nejde v JOSM si tu hotovou cestu
ve tvaru bunkru model treba A120 v meritku nejak ulozit a pak ji
rovnou pouzit jako nejaky Preset?

Diky,

Dalibor

---
Vašek

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Jestli to dobře chápu, tak na tohle by měl stačit CTRL+C +V a pak s 
pridrzenym shift+controlem muzes budovu otacet podle středu. CTRL+ALT 
změna měřítka


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

Re: [Talk-cz] Fwd: Skoleni zakladu OpenStreetMap

2013-05-09 Per discussione Pavel Zbytovský

ad Martin Landa) Další termín teď stanoven není, ale plánuji ho na konec
května. Ještě bych předeslal, že je to čistě moje iniciativa a náhodou to
vyšlo na FITu, kde studuji. Až se bude naše fakulta nějak více zabývat OSM,
moc rád to zkoordinuju i s tvou fakultou. Ozvu se přímo na mail.


ad tracklogy) Nikdy jsem se nezmínil, že by kešeři měli posílat své
tracklogy :-) Mým cílem je naučit do mapy přispívat na úrovni a pokud k
tomu použijou jako jeden ze zdrojů svůj tracklog, tak je to myslím jedině
dobře.


PZ.






2013/5/7 Jachym Cepicky jachym.cepi...@gmail.com

 Zpátky k tématu: Cachery bych do toho netahal, pro všechny již zmíněné
 důvody a další: nikdo příčetný přece nebude sdílet tracklog cesty ke
 cashce?

 Bikeři jsou v tomhle opravdu použitelnější

 J

 Dne 7.5.2013 09:34, Petr Holub napsal(a):
  Kazdy mame nejake pozadavky na presnost mapy, nicmene v ramci OSM bychom
  se asi meli vsichni snazit zakreslit to tak presne, jak to dokazeme.
  A presnost +-20 metru aspon mne osobne neuspokojuje, protoze to uz
  v rade oblasti muze znamenat taky jinou cestu :) Samozrejme kazdy mame
  ty hranice, s nimiz uz jsme spokojeni, nastavene nekde jinde :) U mne
  je to pri beznem pouziti tak +-2 metry :)
 
  Jeste abych nerozdmychal zbytecne vasne. Duvod pro ty +-2m je v tom,
  ze je to vzdalenost radove srovnatelna s veliokosti objektu mapovanych
  v OSM, tedy sirek cest, velikosti budov atd. Tedy jeste lepe by bylo
  +-1m, ale to uz se posovame  asi hodne do profi oblasti :(.
 
  S pozdravem
  Petr
 
 
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-cz
 

 --
 Jachym Cepicky
 Help Service - Remote Sensing s.r.o.
 jachym.cepi...@gmail.com
 HS-RS: jac...@hsrs.cz http://bnhelp.cz
 http://les-ejk.cz


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




2013/5/7 Jachym Cepicky jachym.cepi...@gmail.com

 Zpátky k tématu: Cachery bych do toho netahal, pro všechny již zmíněné
 důvody a další: nikdo příčetný přece nebude sdílet tracklog cesty ke
 cashce?

 Bikeři jsou v tomhle opravdu použitelnější

 J

 Dne 7.5.2013 09:34, Petr Holub napsal(a):
  Kazdy mame nejake pozadavky na presnost mapy, nicmene v ramci OSM bychom
  se asi meli vsichni snazit zakreslit to tak presne, jak to dokazeme.
  A presnost +-20 metru aspon mne osobne neuspokojuje, protoze to uz
  v rade oblasti muze znamenat taky jinou cestu :) Samozrejme kazdy mame
  ty hranice, s nimiz uz jsme spokojeni, nastavene nekde jinde :) U mne
  je to pri beznem pouziti tak +-2 metry :)
 
  Jeste abych nerozdmychal zbytecne vasne. Duvod pro ty +-2m je v tom,
  ze je to vzdalenost radove srovnatelna s veliokosti objektu mapovanych
  v OSM, tedy sirek cest, velikosti budov atd. Tedy jeste lepe by bylo
  +-1m, ale to uz se posovame  asi hodne do profi oblasti :(.
 
  S pozdravem
  Petr
 
 
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-cz
 

 --
 Jachym Cepicky
 Help Service - Remote Sensing s.r.o.
 jachym.cepi...@gmail.com
 HS-RS: jac...@hsrs.cz http://bnhelp.cz
 http://les-ejk.cz


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


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

Re: [OSM-talk-fr] way dupliqués

2013-05-09 Per discussione Frédéric Rodrigo


Le 08/05/2013 11:46, didier2020 a écrit :

...tour de planete afin de corriger les ways dupliqués
...
bilan des courses depuis mi-mars:
nombre de ways effacés : 100 000, ce qui représente 592 000 nodes



je vais refaire les analyses osmoses pour le reste que j'ai oublié ...


suppression de ways : 40 000,  nodes 140 000 , relations 500
cela concerne les données d'import canvec au canada


Pour canvec il y en a vraiment beaucoup plus que ça. Il y a un problème 
de double inner. Il y a le même problème avec CLC.


http://osmose.openstreetmap.fr/fr/errors/?item=1170class=1

Mais le canada est loin, très loin devant avec les 100 000 doubles inner 
polygonones.


Frédéric.


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

Re: [OSM-talk-fr] tag zone:maxspeed - était Re: Choix d'un projet pour le mois de mai : tag zone:maxspeed

2013-05-09 Per discussione lenny



Le 08/05/2013 11:56, Pieren a écrit :

2013/5/7 Nicolas Dumoulinnicolas_openstreetmap@dumoulin63.net:


Pour les zones 30, ça me satisfait comme ça. À la limite, je veux bien
expliciter le maxspeed=30, mais effectivement, le source:maxspeed me parait
aussi superflu.

Restons simple. Pour désigner une route/rue, seul le tag highway est
requis au minimum. Pour désigner une limite de vitesse, seul le tag
maxspeed est requis au minimum. Tous les autres tags expliquant la
source et type de limitation sont optionnels.

Il me semble que zone:maxspeed a un sens : dans ma commune, j'ai
- une petite rue qui serpente limitée à 30 ; il y a un simple panneau de 
début de limitation à 30 (B14) et un de fin.
- des ensembles de plusieurs rues (écoles, crèche, mairie) avec un 
panneau d'entrée zone à 30 (B30) et de fin zone 30 à chaque fois que 
l'on entre/sort de la zone.


C'est sur que le maxspeed suffit dans les deux cas (je n'ai d'ailleurs 
mis que celui-ci) ; mais, la mairie a certainement voulu signaler des 
choses différentes : http://fr.wikipedia.org/wiki/Zone_30.
Si je laisse ce seul tag et que je le montre à la mairie, ils ne verrons 
pas cette différence qui existe sur le terrain.


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

Re: [OSM-talk-fr] way dupliqués

2013-05-09 Per discussione didier2020

Le jeudi 09 mai 2013 à 11:02 +0200, Frédéric Rodrigo a écrit : 
 Le 08/05/2013 11:46, didier2020 a écrit :
  ...tour de planete afin de corriger les ways dupliqués
ways dupliqués : meme géométrie et meme tag pour etre plus précis 
  ...
  bilan des courses depuis mi-mars:
  nombre de ways effacés : 100 000, ce qui représente 592 000 nodes
 
  je vais refaire les analyses osmoses pour le reste que j'ai oublié ...
 
  suppression de ways : 40 000,  nodes 140 000 , relations 500
  cela concerne les données d'import canvec au canada
 
 Pour canvec il y en a vraiment beaucoup plus que ça. Il y a un problème 
 de double inner. Il y a le même problème avec CLC.
 
 http://osmose.openstreetmap.fr/fr/errors/?item=1170class=1
 
 Mais le canada est loin, très loin devant avec les 100 000 doubles inner 
 polygonones.
la, c'est un probleme de fond car ce sont des scripts qui générent ces doubles 
inner
(CLC, canvec, Qadastre) 
 Frédéric.




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

Re: [OSM-talk-fr] Rendu osm_fr : bassins

2013-05-09 Per discussione Christian Quest

Le 8 mai 2013 19:13, Christophe Jacquet christophe.jacq...@gmail.com a écrit :
 Bonjour,

 Bravo pour le rendu osm_fr ! Voici trois suggestions :


 1) Bassins écréteurs de crue :

 Un exemple : http://www.openstreetmap.org/browse/way/42273796

 Si j'en crois le wiki
 (http://wiki.openstreetmap.org/wiki/Tag:landuse=basin?uselang=fr), ça
 se tague par landuse=basin + basin=detention.

 Le rendu Mapnik par défaut affiche la même chose qu'un lac, ce qui est
 trompeur car la plupart du temps, un tel bassin ne contient pas d'eau
 !

 L'IGN représente une successions de lignes bleues horizontales plutôt
 qu'un aplat : ça me semble pas mal, pourrait-on avoir la même chose
 sur le rendu fr ?




Est-ce que ça va comme ça ? http://cl.ly/image/2t1f3E0O2T0m


-- 
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

[OSM-talk-fr] Aéroports et Lieux - rendu osm-fr


Salut,

Tant qu'on est tous en train de peaufiner sur le rendu fr pour en faire 
un rendu de feu, je me permet d'ajouter deux points qui me gênent.


*1. Les aérodromes*
Un aérodrome est vraiment un lieu où personne ne va, sauf les amateurs, 
les afficher dès le zoom 10 donne des chose spéciales, exemple :

http://tile.openstreetmap.fr/?zoom=10lat=42.93942lon=0.40381layers=B0F

*2. Les noms de villes*
Ils sont à mes yeux trop petit, il faut avoir de bons yeux pour les voir 
aux zooms 8 et 9, exemple :

http://tile.openstreetmap.fr/?zoom=8lat=43.82173lon=0.72791layers=B0F

*3. Les surfaces*
La carte ressemble parfois plus à un tableau qu'à une carte du au choix 
de représenter les landuse par des couleurs unies (les cartes TOPO et 
autres n'utilisent pas cette représentation), je suis pour ma part 
contre l'idée du rendu officiel des landuse en couleurs unies.
Mais si vous y tenez, est-il possible d'intensifier la couleur avec le 
zoom ? (en ajoutant un calque blanc transparent entre les landuse et les 
routes, POI et éléments aux dessus, la transparence du calque diminuant 
avec le zoom progressif).

Exemple d'une zone illisible : Les Landes :
http://tile.openstreetmap.fr/?zoom=9lat=44.19411lon=-0.3103layers=B0F

Voilà pour moi chef !

Merci encore.

--
OpenSourceWay
  skype : opensourceway
  opensourceway.fr.nf

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

Re: [OSM-talk-fr] Rendu osm_fr : bassins

2013-05-09 Per discussione David Crochet


Bonjour

Le 09/05/2013 13:18, Christian Quest a écrit :

Est-ce que ça va comme ça ? http://cl.ly/image/2t1f3E0O2T0m


C'est une représentation que j'ai jamais vue telle que, donc cela fait 
drôle au départ.


Cordialement


--
David Crochet

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

Re: [OSM-talk-fr] Aéroports et Lieux - rendu osm-fr

2013-05-09 Per discussione Christian Quest

Le 9 mai 2013 13:38, OpenSourceWay opensource...@laposte.net a écrit :
 Salut,

 Tant qu'on est tous en train de peaufiner sur le rendu fr pour en faire un
 rendu de feu, je me permet d'ajouter deux points qui me gênent.

 1. Les aérodromes
 Un aérodrome est vraiment un lieu où personne ne va, sauf les amateurs, les
 afficher dès le zoom 10 donne des chose spéciales, exemple :
 http://tile.openstreetmap.fr/?zoom=10lat=42.93942lon=0.40381layers=B0F


Il y a surtout des données assez bizarre... par exemple Hautacam
Airport... je connais le coin et à ma connaissance il y a une
altisurface (pour hélico) mais aucun aérodrome. Je pense que c'est la
même chose sur pas mal de cas dans la zone.

La majorité provient d'un import (ourairports) d'où les noms en
anglais xxx airport.

A creuser...


 2. Les noms de villes
 Ils sont à mes yeux trop petit, il faut avoir de bons yeux pour les voir aux
 zooms 8 et 9, exemple :
 http://tile.openstreetmap.fr/?zoom=8lat=43.82173lon=0.72791layers=B0F


Oui, il y a pas mal à revoir pour les noms de villes. C'est assez
compliqué de trouver une bonne règle de généralisation car en zone
dense (par exemple autour de Paris) c'est limite lisible, et par
ailleurs, on a de grandes zones vides avec les noms écrits en petit.

Actuellement c'est le tag place=* couplé à population=* qui sert à
classifier les noms de villes. Il faudrait peut être aussi prendre en
compte la superficie.

 3. Les surfaces
 La carte ressemble parfois plus à un tableau qu'à une carte du au choix de
 représenter les landuse par des couleurs unies (les cartes TOPO et autres
 n'utilisent pas cette représentation), je suis pour ma part contre l'idée du
 rendu officiel des landuse en couleurs unies.

Quel autre type de rendu verrais-tu à la place que des couleurs unies
à ces échelles intermédiaires ?

 Mais si vous y tenez, est-il possible d'intensifier la couleur avec le zoom
 ? (en ajoutant un calque blanc transparent entre les landuse et les routes,
 POI et éléments aux dessus, la transparence du calque diminuant avec le zoom
 progressif).
 Exemple d'une zone illisible : Les Landes :
 http://tile.openstreetmap.fr/?zoom=9lat=44.19411lon=-0.3103layers=B0F


Je n'y tiens pas particulièrement, j'ai assez peu touché à cet aspect
de la feuille de style OSM, juste éclaircit les landuse=farm/farmland
et assombrit les forêts de résineux.

-- 
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] Aéroports et Lieux - rendu osm-fr

2013-05-09 Per discussione Francescu GAROBY

Pour l'exemple des Landes, je rajouterais l'affichage des bases militaires.
Là, on a un gros trou (au nord de Mont-de-Marsan) dans le landuse. Trou qui
n'et rempli qu'au zoom suivant. Il serait donc peut-être intéressant de
faire apparaitre la base (mais c'est sans doute valable pour d'autres
choses), au moins de manière légère (et la couleur devient de + en +
sombre, au fur et à mesure qu'on zoome).

Francescu


Le 9 mai 2013 13:38, OpenSourceWay opensource...@laposte.net a écrit :

  Salut,

 Tant qu'on est tous en train de peaufiner sur le rendu fr pour en faire un
 rendu de feu, je me permet d'ajouter deux points qui me gênent.

 *1. Les aérodromes*
 Un aérodrome est vraiment un lieu où personne ne va, sauf les amateurs,
 les afficher dès le zoom 10 donne des chose spéciales, exemple :

 http://tile.openstreetmap.fr/?zoom=10lat=42.93942lon=0.40381layers=B0F

 *2. Les noms de villes*
 Ils sont à mes yeux trop petit, il faut avoir de bons yeux pour les voir
 aux zooms 8 et 9, exemple :

 http://tile.openstreetmap.fr/?zoom=8lat=43.82173lon=0.72791layers=B0F

 *3. Les surfaces*
 La carte ressemble parfois plus à un tableau qu'à une carte du au choix de
 représenter les landuse par des couleurs unies (les cartes TOPO et autres
 n'utilisent pas cette représentation), je suis pour ma part contre l'idée
 du rendu officiel des landuse en couleurs unies.
 Mais si vous y tenez, est-il possible d'intensifier la couleur avec le
 zoom ? (en ajoutant un calque blanc transparent entre les landuse et les
 routes, POI et éléments aux dessus, la transparence du calque diminuant
 avec le zoom progressif).
 Exemple d'une zone illisible : Les Landes :

 http://tile.openstreetmap.fr/?zoom=9lat=44.19411lon=-0.3103layers=B0F

 Voilà pour moi chef !

 Merci encore.

 --
 OpenSourceWay
   skype : opensourceway
   opensourceway.fr.nf


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://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] Aéroports et Lieux - rendu osm-fr

Le 09/05/2013 13:05, Christian Quest a écrit :

Le 9 mai 2013 13:38, OpenSourceWay opensource...@laposte.net a écrit :

Salut,

Tant qu'on est tous en train de peaufiner sur le rendu fr pour en faire un
rendu de feu, je me permet d'ajouter deux points qui me gênent.

1. Les aérodromes
Un aérodrome est vraiment un lieu où personne ne va, sauf les amateurs, les
afficher dès le zoom 10 donne des chose spéciales, exemple :
http://tile.openstreetmap.fr/?zoom=10lat=42.93942lon=0.40381layers=B0F

Il y a surtout des données assez bizarre... par exemple Hautacam
Airport... je connais le coin et à ma connaissance il y a une
altisurface (pour hélico) mais aucun aérodrome. Je pense que c'est la
même chose sur pas mal de cas dans la zone.

La majorité provient d'un import (ourairports) d'où les noms en
anglais xxx airport.

A creuser...
Autant pour moi, on à des zones comme ça un peu partout (et pas qu'en
France), mais les aérodromes sont fréquentés uniquement par des
passionnés, je trouve mal placé de les mettre autant en valeur.

2. Les noms de villes
Ils sont à mes yeux trop petit, il faut avoir de bons yeux pour les voir aux
zooms 8 et 9, exemple :
http://tile.openstreetmap.fr/?zoom=8lat=43.82173lon=0.72791layers=B0F

Oui, il y a pas mal à revoir pour les noms de villes. C'est assez
compliqué de trouver une bonne règle de généralisation car en zone
dense (par exemple autour de Paris) c'est limite lisible, et par
ailleurs, on a de grandes zones vides avec les noms écrits en petit.

Actuellement c'est le tag place=* couplé à population=* qui sert à
classifier les noms de villes. Il faudrait peut être aussi prendre en
compte la superficie.

3. Les surfaces
La carte ressemble parfois plus à un tableau qu'à une carte du au choix de
représenter les landuse par des couleurs unies (les cartes TOPO et autres
n'utilisent pas cette représentation), je suis pour ma part contre l'idée du
rendu officiel des landuse en couleurs unies.

Quel autre type de rendu verrais-tu à la place que des couleurs unies
à ces échelles intermédiaires ?

Mais si vous y tenez, est-il possible d'intensifier la couleur avec le zoom
? (en ajoutant un calque blanc transparent entre les landuse et les routes,
POI et éléments aux dessus, la transparence du calque diminuant avec le zoom
progressif).
Exemple d'une zone illisible : Les Landes :
http://tile.openstreetmap.fr/?zoom=9lat=44.19411lon=-0.3103layers=B0F

Je n'y tiens pas particulièrement, j'ai assez peu touché à cet aspect
de la feuille de style OSM, juste éclaircit les landuse=farm/farmland
et assombrit les forêts de résineux.
Le rendu en surface est peut-être bien en fait (je n'ai pas d'autres
idées) mais voici trois exemples de cartes plus lisibles (à mes yeux).
En forçant les routes et éclaircissant le reste.

http://mc.bbbike.org/mc/?lon=0.04218lat=43.56469zoom=8num=4mt0=mapnik-germanmt1=google-mapmt2=hike_bikemt3=mapnik

--
OpenSourceWay
skype : opensourceway
opensourceway.fr.nf

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

Re: [OSM-talk-fr] Aéroports et Lieux - rendu osm-fr

Je suis complètement d'accord avec toi, le trou est gênant, mais est du 
au vide de la carte dans la base. Si la base serais mappée le résultat 
serait parlant.
Dans ce cas il faut prendre en compte la surface et n'afficher que les 
grandes bases. Pour ne pas avoir du rouge partout.


Le 09/05/2013 13:15, Francescu GAROBY a écrit :

Pour l'exemple des Landes, je rajouterais l'affichage des bases militaires.
Là, on a un gros trou (au nord de Mont-de-Marsan) dans le landuse. Trou qui
n'et rempli qu'au zoom suivant. Il serait donc peut-être intéressant de
faire apparaitre la base (mais c'est sans doute valable pour d'autres
choses), au moins de manière légère (et la couleur devient de + en +
sombre, au fur et à mesure qu'on zoome).

Francescu


--
OpenSourceWay
  skype : opensourceway
  opensourceway.fr.nf


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

Re: [OSM-talk-fr] Aéroports et Lieux - rendu osm-fr

2013-05-09 Per discussione Francescu GAROBY

Mais la base est mappée (au moins sa superficie), et on la voit au zoom 10.
Là on passe du vide (zoom 9) à une surface rouge hachurée (zoom 10), sans
raison.

Francescu


Le 9 mai 2013 14:26, OpenSourceWay opensource...@laposte.net a écrit :

 Je suis complètement d'accord avec toi, le trou est gênant, mais est du au
 vide de la carte dans la base. Si la base serais mappée le résultat serait
 parlant.
 Dans ce cas il faut prendre en compte la surface et n'afficher que les
 grandes bases. Pour ne pas avoir du rouge partout.

 Le 09/05/2013 13:15, Francescu GAROBY a écrit :

  Pour l'exemple des Landes, je rajouterais l'affichage des bases
 militaires.
 Là, on a un gros trou (au nord de Mont-de-Marsan) dans le landuse. Trou
 qui
 n'et rempli qu'au zoom suivant. Il serait donc peut-être intéressant de
 faire apparaitre la base (mais c'est sans doute valable pour d'autres
 choses), au moins de manière légère (et la couleur devient de + en +
 sombre, au fur et à mesure qu'on zoome).

 Francescu


 --
 OpenSourceWay
   skype : opensourceway
   opensourceway.fr.nf


 __**_
 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] Vrai-faux aerodromes (etait: Aéroports et Lieux...)

2013-05-09 Per discussione Dominique Rousseau

Le Thu, May 09, 2013 at 02:05:40PM +0200, Christian Quest 
[cqu...@openstreetmap.fr] a écrit:
 Le 9 mai 2013 13:38, OpenSourceWay opensource...@laposte.net a écrit :
  1. Les aérodromes
(...)
 
 Il y a surtout des données assez bizarre... par exemple Hautacam
 Airport... je connais le coin et à ma connaissance il y a une
 altisurface (pour hélico) mais aucun aérodrome. Je pense que c'est la
 même chose sur pas mal de cas dans la zone.
 
 La majorité provient d'un import (ourairports) d'où les noms en
 anglais xxx airport.
 
 A creuser...

Ça pourrait faire l'objet d'un test osmose, peut-être ?

-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] Vrai-faux aerodromes (etait: Aéroports et Lieux...)