date:20111122

Am 22. November 2011 08:29 schrieb Jannis Achstetter kri...@gmail.com:
 Am 22.11.2011 07:09, schrieb Manuel Reimer:
 Bernhard Weiskopf bweiskopf at gmx.de writes:
 Die Fläche habe ich als Polygon gezeichnet und weil ich kein passendes tag
 gefunden habe, habe ich das allgemeine area verwendet:
 area = yes
 name = (Name der Fläche, hier das Flurstück)


das sagt noch gar nichts über die Natur des Objekts aus. Wenigstens
einen note-tag mit einer Erläuterung für kommende Mapper würde ich
ergänzen, wenn Du schon selbst keinen tag verwenden willst, der das
Objekt beschreibt.


 Ich hätte vermutlich das landuse=farmland zerhackt.


was aber auch nichts ändert: die Flur wäre dann immer noch nicht durch
tags beschrieben.


 Ich werde mal prüfen, wie viele Flurnamen es hier tatsächlich gibt. Wenn das
 nicht überhand nimmt, dann trage ich die Namen als Node ein. Wenn die Gefahr
 besteht, die Darstellung zu verhunzen, dann lasse ich es sein.


place=locality hat wohl ein Problem, auch wenn es formal oft passt,
weil dieses Tag zu allgemein ist, und daher verschiedene Dinge in
einen Pott geworfen werden. Eine verhunzte Darstellung auf
Datenbank-seite durch Feature-löschen/vermeiden zu korrigieren halte
ich bei einem so verbreiteten und topographisch interessanten Feature
wie Flurnamen jedenfalls für den absolut falschen Weg. Da bisher kaum
einer Flurnamen eingetragen hat, sind auch sehr wahrscheinlich die
Renderregeln noch nicht optimiert. Erst durch eine verhunzte
Darstellung kann man die Stylesheet-maintainer darauf aufmerksam
machen und auf Änderung hoffen.


Gruß Martin

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

Re: [Talk-de] Dictonaries in OSM

Am 20. November 2011 03:59 schrieb Andreas Hubel a...@saerdnaer.de:
 Mir sind im ersten Moment nur die TMC und die parking Tags eingefallen:
 parking:lane:right=perpendicular
 parking:condition:right=disc
 parking:condition:right:maxstay=1 h
 parking:condition:right:time_interval=Mo-Fr 09:00-18:00;Sa 09:00-14:00

 parking = {
        lane: {
                right: perpendicular
        },
        condition: {
                right: {
                        value: disc,
                        maxstay: 1 h,
                        time_interval: [Mo-Fr 09:00-18:00, Sa 09:00-14:00]
                }
        }
 }


das könnte man auch anders rum machen (also erst rechts/links = die
Angabe des Subobjekts, und dann erst die zugehörigen tags (verkürzt
wiedergegeben): parking={lane:{right:{condition: {disc, maxstay,
timeinterval}, surface: asphalt, width: 2.5m}}} bzw. klassisch
parking:lane:right:condition=...

Alternativ könnte man auch dedizierte Geometrie verwenden, dann würde
das meiste schonmal wegfallen (parking:lane:right). Das ist wenn man
nur an den Park-details interessiert ist, vielleicht nicht nötig, aber
vermutlich wird man irgendwann auch weitere Details wie die
Unterbrechungen der seitlichen Parkplätze (z.B. Fußgängerquerung),
mappen wollen, und dafür jedesmal die Straße zu splitten ist auch
weniger schön.


 Ich wäre grundsätzlich dafür beim Taggen drauf zu achten, das möglichst wenig 
 verschiedene Keys entstehen.
 Das heißt ich würde dynamische Dinge wie Zahlen oder Wochentage gerne aus dem 
 Key rauslassen.


+1


 Ggf. sollte man dann auch noch ein einheitliches Trennzeichen für subkey und 
 subvalue einführen, z.B. den Doppelpunkt.


das haben wir mehr oder weniger bereits. Einziger Haken: neben dem
Doppelpunkt gibt es noch den underscore, der in bestimmten Fällen eine
ähnliche Rolle einnimmt.


 level_names:U=basement
 level_names:G=ground floor
 level_names:3=roof

 Oder sollte man doch einfach JSON in den Value stecken?
 level_names={U: basement, G: ground floor, 3: roof}


würde m.E. in diesem Beispiel hier Sinn machen.


 Wie sieht ihr das?
 Macht es Überhaupt sinn da ne einigermaßen einheitliche Regel zu erarbeiten?


Danke für diese Mail. Das ist ein Thema, das regelmäßig hochkommt, die
Welt ist nun mal komplex.


Naja, Sinn. Einerseits erhöht es die Komplexität für den Mapper (er
muss sich jetzt auch noch ein paar Regeln zur Notation merken),
andererseits würde ein fester Satz Regeln vermutlich die Bereitschaft
erhöhen, komplexere Sachverhalten auch abzubilden, und bestimmte tags
würden auch übersichtlicher durch diese Art der Notation (s.d.
Beispiele). Ausserdem könnte man die gestiegene Komplexität durch den
Editor geschickt verbergen / einfach zugänglich machen.

Grundsätzlich gibt es allerdings wohl Bedenken von Seiten der
Entwickler gegen Werte, die erst durch Parsen und Weiterverarbeiten
des Wertstrings Sinn ergeben, weil das die Auswertung verlangsamt
(bereits das Semikolon als Werte-trenner wird von den Hauptanwendungen
wie osm2pgsql soweit ich weiss nicht gesondert berücksichtigt, erst
recht keine Dictionaries), und weil eine rasche Verarbeitung bei den
von uns gebräuchlichen Datenmengen unabdingbar ist (vor allem, wenn
man die globalen Daten vorhalten will).

Gruß
Martin

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

Re: [Talk-de] Tablet-PC: Android oder iPad?

Am 20. November 2011 23:41 schrieb Robert Kaiser ka...@kairo.at:
 koppenho schrieb:
 wir (meine Frau und ich) stehen gerade vor der Wahl eines Tablet-PCs.
 In der engeren Auswahl stehen Sony Tablet S 3G und Apple iPad 2 mit
 Wi-Fi + 3G.

 Mit dem iPad kannst du nur Apps installieren, die Apple erlaubt und die
 keine Konkurrenz zu irgendeinem Apple-Angebot sind.


genauer gesagt kann man nur das installieren, was man über den
Appstore von Apple bezieht. Und bei Bedarf kann Apple sogar aus der
Ferne Applicationen von Deinem Gerät löschen - zu Deiner eigenen
Sicherheit ;-) (das macht Google allerdings wohl auch:
http://www.golem.de/1103/81927.html ).
Da es fürs iPad kein Java gibt (zumindest ohne Jailbreak), würde JOSM
da ausscheiden.


 Auf Android kannst du installieren, was du willst, und es gibt auch sowohl
 eine Menge Apps, die OSM verwenden, als auch, mit denen man OSM bearbeiten
 kann.


von Android gibt es im Gegenzug einige Versionen im Umlauf, die
untereinander nicht vollständig kompatibel sind.


 Ich denke, dass die Oberfläche von JOSM, falls es laufen würde, kaum für
 einen Touchscreen verwendbar ist, aber so weit ich gesehen habe, gibt es
 Apps, die da besser optimiert sind.


habe es nie ausprobiert, aber es gibt ein Plugin für JOSM für
Touchgeräte (touchscreenhelper). Ob das alles bietet, was man braucht
um mit einem Touchscreen zu mappen kann ich Dir allerdings nicht
sagen.

Gruß Martin

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

2011-11-22 Per discussione bkmap


Am 20.11.2011 14:14, schrieb Martin Koppenhoefer:

Am 19. November 2011 22:31 schrieb Wolfgangwolfg...@ivkasogis.de:

Wie gesagt, Behindertennavigation ist eine andere Sache, aber Wattwege
grundsätzlich aus OSM oder allen Amwendungen herausnehmen zu wollen, halte ich
für reichlch übertrieben.



das war glaube ich auch nicht die Forderung. Überlegbar wäre doch
z.B., ob man einen eigenen Wert für den highway-tag einführt, so dass
diese Wege nur dann berücksichtigt werden, wenn die Anwendung sie
kennt (und sich der Programmierer überlegen kann, wie er sie
präsentiert).



Warum nicht etwa so:
highway=path
access=no
foot=high_tide+2-low_tide+0:30

oder

highway=path
access=no
foot:hour_on=high_tide+2h
foot:hour_off=low_tide+30min

Jede auswertesoftware, die mit den Zeiten nicht zurechtkommt, zeigt den 
Pfad dann als gesperrt an.


Gruß Burkhard


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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

Am 22. November 2011 14:10 schrieb bkmap burkhard.kirch...@web.de:
 Am 20.11.2011 14:14, schrieb Martin Koppenhoefer:

 Am 19. November 2011 22:31 schrieb Wolfgangwolfg...@ivkasogis.de:

 Wie gesagt, Behindertennavigation ist eine andere Sache, aber Wattwege
 grundsätzlich aus OSM oder allen Amwendungen herausnehmen zu wollen,
 halte ich
 für reichlch übertrieben.


 das war glaube ich auch nicht die Forderung. Überlegbar wäre doch
 z.B., ob man einen eigenen Wert für den highway-tag einführt, so dass
 diese Wege nur dann berücksichtigt werden, wenn die Anwendung sie
 kennt (und sich der Programmierer überlegen kann, wie er sie
 präsentiert).


 Warum nicht etwa so:
 highway=path
 access=no
 foot=high_tide+2-low_tide+0:30

 oder

 highway=path
 access=no
 foot:hour_on=high_tide+2h
 foot:hour_off=low_tide+30min

 Jede auswertesoftware, die mit den Zeiten nicht zurechtkommt, zeigt den Pfad
 dann als gesperrt an.


das ist hacking für den Router, da es ja gar nicht verboten ist, den
Weg zu nutzen, es ist nur zu bestimmten Zeiten unmöglich (bzw. gibt
es den Weg gar nicht, wenn Flut ist), das ist was ziemlich anderes als
mit diesem Mapping ausgedrückt würde.

Gruß Martin

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

2011-11-22 Per discussione Chris66

Am 22.11.2011 14:38, schrieb Martin Koppenhoefer:

 Warum nicht etwa so:
 highway=path
 access=no
 foot=high_tide+2-low_tide+0:30

 oder

 highway=path
 access=no
 foot:hour_on=high_tide+2h
 foot:hour_off=low_tide+30min

 Jede auswertesoftware, die mit den Zeiten nicht zurechtkommt, zeigt den Pfad
 dann als gesperrt an.

 das ist hacking für den Router, da es ja gar nicht verboten ist, den
 Weg zu nutzen, es ist nur zu bestimmten Zeiten unmöglich (bzw. gibt
 es den Weg gar nicht, wenn Flut ist), das ist was ziemlich anderes als
 mit diesem Mapping ausgedrückt würde.

Naja, auf absehbare Zeit kommen die wenigsten Router mit solchen
Konstrukten zurecht und da ist es IMHO ok, wenn solche temporären
Wege standardmäßig *nicht* routbar sind.

Im schlimmsten Fall geht es um Menschenleben, siehe kürzliche Meldung
des LKW Fahrers der sich von seinem Navi in den Rhein leiten ließ.

Chris


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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

Am 22. November 2011 15:00 schrieb Chris66 chris66...@gmx.de:
 Naja, auf absehbare Zeit kommen die wenigsten Router mit solchen
 Konstrukten zurecht und da ist es IMHO ok, wenn solche temporären
 Wege standardmäßig *nicht* routbar sind.


völlig einverstanden. Warum macht man solche Verrenkungen und nimmt
nicht einfach einen neuen Wert für highway, z.B.

highway=tidal_road für Straßen und
highway=tidal_path für Wege (falls es das gibt)

ein Weg im Watt ist nunmal ein eigener Typ Weg mit eigener
Charakteristik, der in vielen Anwendungen grundsätzlich anders
behandelt werden muss als ein Weg auf dem Trockenen.

Gruß Martin

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

2011-11-22 Per discussione Andreas Neumann

On 11/22/2011 03:19 PM, Martin Koppenhoefer wrote:
 Am 22. November 2011 15:00 schrieb Chris66 chris66...@gmx.de:
 Naja, auf absehbare Zeit kommen die wenigsten Router mit solchen
 Konstrukten zurecht und da ist es IMHO ok, wenn solche temporären
 Wege standardmäßig *nicht* routbar sind.

 völlig einverstanden. Warum macht man solche Verrenkungen und nimmt
 nicht einfach einen neuen Wert für highway, z.B.

 highway=tidal_road für Straßen und
 highway=tidal_path für Wege (falls es das gibt)

 ein Weg im Watt ist nunmal ein eigener Typ Weg mit eigener
 Charakteristik, der in vielen Anwendungen grundsätzlich anders
 behandelt werden muss als ein Weg auf dem Trockenen.

 Gruß Martin

Moin,

Genauso fände ich es gut, wenn für die OSM-Karten, die für die
Garmin-Autonavigation zur Verfügung gestellt werden, Furt als Blockade
sehen... Jedenfalls hier in Deutschland.

MfG Andreas



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

Re: [Talk-de] Dictonaries in OSM

2011-11-22 Per discussione Frederik Ramm


Hallo,

On 11/20/11 03:59, Andreas Hubel wrote:

Wie sieht es nun aber mit Dictonaries aus?
Leider ist man sich da wohl nicht so einig.
Mir sind im ersten Moment nur die TMC und die parking Tags eingefallen:


Beide sind sehr unglueckliche Beispiele, die von Menschen nicht mehr gut 
handhabbar sind.



Oder sollte man doch einfach JSON in den Value stecken?


Halte ich fuer eine ganz schlechte Idee.


Wie sieht ihr das?


Wo irgend moeglich, sollte man sich nicht fragen, wie man diese 
Komplexitaet am besten abbilden kann, sondern ob es sich vielleicht 
vermeiden laesst.


Man sollte ich fragen:

* Wer hat was davon, diese Informationen zu sammeln?
* Gibt es *irgendeine* real existierende Anwendung, die diese 
Informationen nutzt?
* Wie sicher sind diese Informationen dagegen, durch Fehl-Edits oder 
Verstauben (was niemand sieht, aktualisiert auch niemand) kaputtzugehen?


Viel zu viele Mapper stehen mit den Augen eines Datenbankprogrammierers 
vor dem Objekt in der realen Welt und fragen sich: Welche Eigenschaften 
hat dieses Objekt, die man modellieren koennte?


Bye
Frederik

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

Hallo Liste,
hallo Christian!

 am Freitag, 18. November 2011 um 15:30 schrieb lulu-...@gmx.de:
  Wanderweg Cuxhafen - Neuwerk durch's Watt bekommt dann
  Opening_Hours=Niedrigwasser-2h bis Niedrigwasser+1h

Christian: 
 Aber das benutzt Du bitte bitte bitte bitte NICHT für Dein
 Blindenrouting.
 
 Ich finde es sowieso schon zweifelhaft daß Wege durchs Watt
 eingetragen sind.

Ob ein Blinder einen Weg durchs Watt benutzen möchte, bleibt ihm überlassen.
(Blind ist nicht unmündig. Dummheit und Blindheit sind durchaus unabhängig, und 
auch Sehenden räumt man Unvernunft ein...)

Ich würde es auch Sehenden nicht raten, sich uninformiert und oder ungeführt 
und oder allein ins Watt zu begeben.
Mit GPS, Backup-GPS und Handy sehe ich aber kaum Zusatz-Probleme durch die 
Blindheit, und mit Führhund schon gar nicht.
Und Füße an Muscheln aufzuschneiden ist vom Hingucken völlig unabhängig!

Der Weg nach Neuwerk ist immerhin mit Rettungskörben versehen, also macht es 
großen Sinn, ihn einzutragen, damit die Leute nicht einen Kilometer *neben* den 
Körben durchs Watt laufen.

(Wie taggt man Rettungskörbe eigentlich? Ah: Sie sind schon eingetragen auf 
Node mit Highway:Emergency Access Point)

Im Gegenteil, als touristisches Highlight mit dem super hohem taktilen 
Erlebnis-Wert würde ich Blinden eine geführte Wattwanderung sogar empfehlen!

In diesem Sinne: Die Rollstuhl-Nicht-Eignung darfst Du auch gerne an Via 
Ferrata-Tags drankleben, aber nicht die Blinden-Nicht-Eignung.
Es gibt nämlich auch geführte Blinden-Bergwander-Touren...
Öhm... Dog=no würde ich an Via Ferrata schreiben.

Aber tröste Dich, auch ich habe gestaunt, was (manche) Blinde alles können und 
machen, als ich die ersten kennengelernt habe. 
Deine Einschätzung ist also nicht verwunderlich.

Ich mache jetzt gleich mal einen attraction-Tag an den Wattwanderweg. Mit 
blind:description:de.

In diesem Sinne
Lulu-Ann

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

[Talk-de] Request for comments, Re: Tidenzeiten

Hi Liste,
hi Peter!

 also tidal=yes halte ich für grob fahrlässig generell für Wege, die im 
 Zweifelsfall tatsächlich gefährlich sind...

Bis wir was Besseres haben, ist das besser als gar keine Tiden-Markierung.
 
 Aber wenigstens kenn ich's jetzt, werds mir aufschreiben und hoffentlich 
 dran denken, Wege mit dem Tag zu ignorieren.

Brauchst Du nicht.
Du hast ja irgendwie recht, darum hab ich mal eben schnell ein neues Proposal 
gestrickt:

 Trotzdem würd ich das keiner Anwendung verübeln, das Tag nicht zu 
 berücksichtigen, und halte das Tagging hier für grob fahrlässig; 
 wesentlich schlimmer noch als construction=yes, disused=yes oder sowas.

Das ist mit dem neuen Tagging dann alles hinfällig.

 Tags sollten die Bedeutung anderer Tags nicht umdrehen. Dies ist mal 
 wieder ein Paradebeispiel, warum das so ist.

+1, und darum:

http://wiki.openstreetmap.org/wiki/Proposed_features/Tidalflat_path

Gruß
Lulu-Ann


-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

Hallo Liste,
hallo Johannes!

Johannes schieb: 
 Mindestens beim Blindenrouting ist ein Hinweis des Geräts angebracht, 
 dass man dabei ist eine coastline zu kreuzen ... 
 
 Blinde würden aber ohnehin merken, wenn sie im Watt stehen.

Wenn sie mit den Füßen im Watt stehen, würden sie es natürlich genau wie Du 
merken.

Aber wenn sie zu Hause vorm Rechner sitzen und eine Route von Cuxhaven nach 
Neuwerk planen, dann muß entweder das Watt oder das Meer oder die Eigenschaft 
des Weges angesagt werden.
Das sind Dinge, die der Sehende aufgrund der Färbung der Flächen gleich 
wahrnehmen würde. 
Traditionelles Routing beachtet aber die Flächen drumrum und drunter nicht. 
Da muß man schon aktiv werden und der Routing Engine Hilfen anbieten (am Weg 
taggen) oder Flächen berücksichtigen (das ist das, was du als Kreuzen der 
Coastline vorschlägst. Routing bemerkt normal halt keine kreuzenden 
unverbundenen Vektoren. Das wäre auch eine kollosale Verlangsamung, solch eine 
Prüfung einzubauen).

Die Erkenntnis vor Ort ist für jeden, der am/im Watt steht dann zu spät.
Ich werde mal rumfragen, ob schon jemand seinen Führhund dazu bekommen hat, 
durchs Watt mitzugehen.

Schöne Grüße
Lulu-Ann


-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

Hallo Liste,
hallo Heiko!

 Am 18.11.2011 15:30, schrieb lulu-...@gmx.de:
  Wanderweg Cuxhafen - Neuwerk durch's Watt bekommt dann
 
 Richtige Havenstädte schreiben sich mit v!

Vataler Veler meinerseits.
 
  Opening_Hours=Niedrigwasser-2h bis Niedrigwasser+1h
 
  und wann Tide ist kann man aus dem Längengrad errechnen. Allns kloar?
 
 Da spielt lokal noch 'n beten mehr als der Längengrad rein ...

Eben genau dafür ist ja die Konstante!
Die Tide ist nur der Grundwert.
Ein Zeitversatz gegen die theoretische Tide nach Längengrad, z.B. durch 
Umspülung eines inseligen Hindernisses kann dann entsprechend angegeben werden.

Gruß
Lulu-Ann
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

Re: [Talk-de] Defibrator-Mappen

Hallo Liste, hallo Christian!

Christian schrieb:
 Ich habe gerade das hier zum Thema Defibrillatoren gefunden, kann man die
 evtl. mit einarbeiten?
 
 http://www.stepmap.de/atlas.php?autor=region1=region2=region3=stichwort=defibrillatorfreiesuche=suchbereich=seite=1sortierung=1sortrichtung=0

Dies ist eine Doocracy. Mach doch! Wen meinst Du bloß mit man ?

Berücksichtigen: Unter welchem Copyright stehen die Kartendaten?

Mein Vorschlag: Versuch doch den Autor zu kontaktieren, und ihn mit der Nase 
auf OSM zu stupsen. Vermutlich macht sich der Rest der Arbeit dann von allein.

Gruß
Lulu-Ann
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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

Re: [Talk-de] Defibrator-Mappen

2011-11-22 Per discussione UMAX974

Tschuldigung, war nicht im Sinn von macht mal gemeint (ich kann so was schon
auch selbst ) , sonder eher als Hinweis gedacht, dass es da was gibt -
Vermutlich sind die Daten bei stepmap auch noch so ungenau, dass sie für einen
Übertrag als POI nach OSM so noch nicht geeignet sind. Aber es könnt für
manchen der in der Umgebung der angegebenen Orte lebt und mapt, ein Hinweis
sein, dort noch mal genauer nachzusehen und die Dinger präziser zu mappen. Ich
versuch's gerade hier für die Gegen rauszubekommen

Gruß
Christian

Am 22.11.2011 um 17:43 schrieb lulu-...@gmx.de:

Hallo Liste, hallo Christian!

Christian schrieb:
Ich habe gerade das hier zum Thema Defibrillatoren gefunden, kann man die
evtl. mit einarbeiten?

http://www.stepmap.de/atlas.php?autor=region1=region2=region3=stichwort=defibrillatorfreiesuche=suchbereich=seite=1sortierung=1sortrichtung=0

Dies ist eine Doocracy. Mach doch! Wen meinst Du bloß mit man ?

Berücksichtigen: Unter welchem Copyright stehen die Kartendaten?

Mein Vorschlag: Versuch doch den Autor zu kontaktieren, und ihn mit der Nase
auf OSM zu stupsen. Vermutlich macht sich der Rest der Arbeit dann von allein.

Gruß
Lulu-Ann
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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

Re: [Talk-de] Request for comments, Re: Tidenzeiten

Am 22. November 2011 16:43 schrieb  lulu-...@gmx.de:
 +1, und darum:

 http://wiki.openstreetmap.org/wiki/Proposed_features/Tidalflat_path


+1, finde ich gut, müsste aber doch highway=tidal_flat_path sein, oder?
Was hältst Du von tidal_path? Dann mache ich noch ein tidal_road
Proposal [1] dazu, dann sollte man das Watt abgedeckt haben.

Gruß Martin

[1] http://www.wetroads.co.uk/tidal.htm

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

Re: [Talk-de] Request for comments, Re: Tidenzeiten

Am 22. November 2011 19:24 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 22. November 2011 16:43 schrieb  lulu-...@gmx.de:
 +1, und darum:

 http://wiki.openstreetmap.org/wiki/Proposed_features/Tidalflat_path


 +1, finde ich gut, müsste aber doch highway=tidal_flat_path sein, oder?
 Was hältst Du von tidal_path? Dann mache ich noch ein tidal_road
 Proposal [1] dazu, dann sollte man das Watt abgedeckt haben.

done:
http://wiki.openstreetmap.org/wiki/Proposed_features/Tidal_road

Gruß Martin

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

[Talk-de] Chemnitzer Linux-Tage 2012

2011-11-22 Per discussione Jens Poenisch


Hallo,

die Vorbereitungen für die Chemnitzer Linux-Tage 2012 laufen inzwischen,
es können Stände, Vorträge und Workshops angemeldet werden:

http://chemnitzer.linux-tage.de

Es wäre schön, wenn OpenStreetMap wieder vertreten ist, der Stand ist
in den letzten Jahren sehr gut angekommen und von den Besuchern
positiv bewertet worden.

Tschüss, Jens

--
Jens Poenisch, EMail: jens.poeni...@ruessel.in-chemnitz.de
- Bisher haben die Astropsychologen noch nicht herausgefunden,
  woran die Elefanten denken. -- T. Pratchett
-An Elefantinnen, meint OJe___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tablet-PC: Android oder iPad?

2011-11-22 Per discussione Frank Huebner

Thomas Reincke m...@thomas-reincke.de writes:

 Am 20.11.2011 11:46, schrieb koppenho:
 Ich möchte gelegentlich das Tablet zum Erfassen für OSM vor Ort nutzen.
 Die Seite http://wiki.openstreetmap.org/wiki/Android habe ich gefunden.
 Die scheint sich aber hauptsächlich auf Android-Smartphones zu beziehen.
 Sind die genannten Apps auch auf einem Tablet sinnvoll einsetzbar?

 Habt Ihr noch ein paar Tips?

 Es klingt so, als ob Du nicht nur erfassen, sondern auch gleich bearbeiten
 willst. Zum Erfassen auf dem Smartphone finde ich Locus sehr gut.

Zum Erfassen mit einem Smartphone nutze ich osmtracker unter
Android. Der Track kann dann als gpx exportiert werden. Die
aufgenommenen Fotos sind im Track verlinkt und werden mit josm (auf dem
PC) an der richtigen Position angezeigt werden.

Es gibt für Smartphones aber auch Apps zum Bearbeiten der Daten. Ich
habe mal mit Vespucci rumgespielt, aber auf einem kleinen Display wollte
ich dann nicht editieren. Auf einem Tablet wird das anders sein.

 Was mir noch wichtig wäre. Ich möchte (insbes. für Punkterfassungen) eine
 externe Maus anschließen können. Ich meine, da wäre trotz Bluetooth beim Apfel
 der Wurm drin.

Mit Bluetooth GPS kann ich unter Android eine externe Maus
nutzen. Insgesondere hilfreich, wenn das eingebaute GPS nicht ganz so
gute Empfangsleistung hat.

Mit iOS kenne ich mich nicht aus, daher die Beschränkung auf Lösungen
unter Android. Aber dank des recht offenen Systems wird sich bei Android
eher etwas finden als unter iOS.

Frank

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

Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]

2011-11-22 Per discussione bkmap


Am 22.11.2011 15:19, schrieb Martin Koppenhoefer:

Am 22. November 2011 15:00 schrieb Chris66chris66...@gmx.de:

Naja, auf absehbare Zeit kommen die wenigsten Router mit solchen
Konstrukten zurecht und da ist es IMHO ok, wenn solche temporären
Wege standardmäßig *nicht* routbar sind.



völlig einverstanden. Warum macht man solche Verrenkungen und nimmt
nicht einfach einen neuen Wert für highway, z.B.

highway=tidal_road für Straßen und
highway=tidal_path für Wege (falls es das gibt)


IMO brauchen wir Gezeiten-Eigenschaften, die wir nicht nur an Straßen 
oder Pfade hängen können. Es gibt ganz sicher noch andere 
gezeitenabhängige Objekte (Parkplätze, Wassersporteinrichtungen, 
nautische Objekte ...). Deshalb bin ich dafür, vorhandene zeitliche 
Restriktionen um die Gezeiten zu erweitern. Dann kann man aus 
Sicherheitsgründen so taggen, dass das Objekt keinen Zugang erlaubt, 
wenn die Anwendung diese zeitliche Einschränkung nicht verarbeiten kann.


Übrigens ist es nicht relevant, ob die Wege bei Niedrigwasser vorhanden 
sind oder nicht, sondern ob der Zugang möglich und sicher ist. Das 
trifft auf Wege entlang der Steilküsten besonders zu. Man kann viele 
Wege am Fuß der Steilküste eigentlich nur begehen, wenn die Ebbe gerade 
einsetzt. Dann kann man dem Wasser sozusagen hinterher laufen. Noch 
bevor die Flut einsetzt sollte man aber schleunigst wieder umkehren, 
damit man nicht in einer der Buchten vom Wasser eingeschlossen wird. 
(Das gilt auch fürs Watt. Man kann da auf leichten Erhebungen vom Wasser 
eingeschlossen werden.)
Wir brauchen ein Tagging, das solche Sachverhalte abbilden kann und das 
für andere gezeitenabhängige Objekte ebenfalls funktioniert (IMO über 
Objekteigenschaften). Router, die das Tagging nicht verstehen, dürfen 
sicherheitshalber nicht über diese Objekte routen.


Gruß Burkhard


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

[Talk-it] Una barrier può venir applicata ad un percorso chiuso ?

Il tag  barrier può venir applicato ad un percorso chiuso ? 

È stato il dubbio  di stamane andando al lavoro, quando ho notato lo
spartitraffico triangolare che separa le corsie in entrata ed in uscita da
una rotatoria, che secondo me sarebbe tutto quanto un kerb ;

 

 

Buonagiornata a tutti,

Ale.

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

Re: [Talk-it] Una barrier può venir applicata ad un percorso chiuso ?

2011/11/22 Alech OSM alech.hos...@gmail.com:
 Il tag  barrier può venir applicato ad un percorso chiuso ?


il tag barrier viene applicato al ostacolo stesso, non al percorso.

ciao,
Martin

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

Re: [Talk-it] Una barrier può venir applicata ad un percorso chiuso ?

2011-11-22 Per discussione Simone Saviolo

Il giorno 22 novembre 2011 09:06, Alech OSM alech.hos...@gmail.com ha
scritto:

 Il tag  barrier può venir applicato ad un percorso chiuso ?

 È stato il dubbio  di stamane andando al lavoro, quando ho notato lo
 spartitraffico triangolare che separa le corsie in entrata ed in uscita da
 una rotatoria, che secondo me sarebbe tutto quanto un “kerb” ;


Direi di sì! Pensa ad una fence, ad esempio.


 Buonagiornata a tutti,

 Ale.


Ciao,

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

[Talk-it] R: Una barrier può venir applicata ad un percorso chiuso ?

Si , ma:
o una recinzione (barrier=fence) è un percorso  un ostacolo ?
Lo spartitraffico davanti alla rotonda è un ostacolo di circa 2mt x 3 mt ??


-Messaggio originale-
Da: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Inviato: martedì 22 novembre 2011 9.31
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Una barrier può venir applicata ad un percorso
chiuso ?

2011/11/22 Alech OSM alech.hos...@gmail.com:
 Il tag  barrier può venir applicato ad un percorso chiuso ?


il tag barrier viene applicato al ostacolo stesso, non al percorso.

ciao,
Martin

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


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

Re: [Talk-it] R: Una barrier può venir applicata ad un percorso chiuso ?

2011-11-22 Per discussione Simone Saviolo

Il giorno 22 novembre 2011 09:51, Alech OSM alech.hos...@gmail.com ha
scritto:

 Si , ma:
 o una recinzione (barrier=fence) è un percorso  un ostacolo ?


...pardon? :-)

Lo spartitraffico davanti alla rotonda è un ostacolo di circa 2mt x 3 mt ??


No: lo spartitraffico davanti alla rotonda è un'area (di erba, di asfalto
dipinto, quello che è), spesso ma non sempre circondato da un gradino. Il
gradino è la barriera.

Ciao,

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

[Talk-it] R: R: Una barrier può venir applicata ad un percorso chiuso ?

Va bene , capito.

Allora, tracciando la classica rotonda con 4 strade intorno:

-  Se disegno solo le aree triangolatri posso copiarne i tag .

-  Se invece ogni area è un multipoligono con la eventuale barriera
in ruolo outer, mica posso copiarne la relazione , vero ?

È possibile invece dare la stessa unica relazione (multipolygon) a tutti e 4
gli spartitraffico ?

 

Ciao,

Ale

 

Da: Simone Saviolo [mailto:simone.savi...@gmail.com] 
Inviato: martedì 22 novembre 2011 9.55
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: Una barrier può venir applicata ad un percorso
chiuso ?

 

Il giorno 22 novembre 2011 09:51, Alech OSM alech.hos...@gmail.com ha
scritto:

Si , ma:
o una recinzione (barrier=fence) è un percorso  un ostacolo ?

 

...pardon? :-)

 

Lo spartitraffico davanti alla rotonda è un ostacolo di circa 2mt x 3 mt ??

 

No: lo spartitraffico davanti alla rotonda è un'area (di erba, di asfalto
dipinto, quello che è), spesso ma non sempre circondato da un gradino. Il
gradino è la barriera. 

 

Ciao,

 

Simone

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

Re: [Talk-it] R: R: Una barrier può venir applicata ad un percorso chiuso ?

2011-11-22 Per discussione Simone Saviolo

Il giorno 22 novembre 2011 10:07, Alech OSM alech.hos...@gmail.com ha
scritto:

 Va bene , capito.

 Allora, tracciando la classica rotonda con 4 strade intorno:

 -  Se disegno solo le aree triangolatri posso copiarne i tag .

 -  Se invece ogni area è un multipoligono con la eventuale
 barriera in ruolo outer, mica posso copiarne la relazione , vero ?

Non ho mai provato a copiare una relazione. Forse in Josm, se selezioni la
relazione nella finestra delle relazioni...


 È possibile invece dare la stessa unica relazione (multipolygon) a tutti e
 4 gli spartitraffico ?


È possibile, ma non lo farei. Non è lo stesso oggetto.


  Ciao,

 Ale


Ciao,

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

[Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

Come da oggetto: la Lombardia sta messo bene nella competizione per la
chiave più lunga. Guardate questa statistica e invertite l'ordine:

http://taginfo.openstreetmap.org/reports/key_lengths#keys

E' pieno di tags del genere:
it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3

vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se
chi importa dati da ctr si tiene un database a parte dove si memorizza
quale entità osm è correllato a quale oggetto / livello della ctr?
Secondome il tag da usare in osm è
boundary=administrative
admin_level=x
non è it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3 o
it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_7-10
informazioni del tipo lista 1 si possono benissimo mettere nel
commento del changeset.

ciao,
Martin

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione sabas88

Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo? :)
No, scherzi a parte, mi sembra che sia un import senza un minimo di
elaborazione, come i confini istat che hanno chiavi simili a quella,
bisognerebbe toglierli ed usare lo standard esistente.
Ciao,
Stefano
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione Federico Cozzi

2011/11/22 Martin Koppenhoefer dieterdre...@gmail.com:
 vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se
 chi importa dati da ctr si tiene un database a parte dove si memorizza
 quale entità osm è correllato a quale oggetto / livello della ctr?

Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non
importarlo.
Se invece permette di correlare gli oggetti OSM con gli oggetti CTR,
allora va importato in OSM perché è l'unico posto che può mantenere
memoria della correlazione (gli ID di OSM possono cambiare ad es. con
split/merge di way, e quindi non sono una buona chiave primaria)

Ciao

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011/11/22 Federico Cozzi f.co...@gmail.com:
 Se invece permette di correlare gli oggetti OSM con gli oggetti CTR,
 allora va importato in OSM perché è l'unico posto che può mantenere
 memoria della correlazione (gli ID di OSM possono cambiare ad es. con
 split/merge di way, e quindi non sono una buona chiave primaria)


non è un problema se cambia l'ID osm. Nello storico viene tutto conservato ;-)

Se faccio un merge / split di una way del genere ho una seria di altri
problemi (dovrei cambiare probabilmente tanti tags, vedi sotto).

Secondome non ha senso replicare il database di un altro ente in OSM,
come è stato fatto qui. Guardate qui:
http://www.openstreetmap.org/browse/way/44356578

admin_level = 8
boundary = administrative
it:lombardia:ctrn:area = 0.0
it:lombardia:ctrn:cod_asl = 4
it:lombardia:ctrn:cod_istat = 19060
it:lombardia:ctrn:cod_istatn = 03019060
it:lombardia:ctrn:cod_pro = 19
it:lombardia:ctrn:cod_reg = 03
it:lombardia:ctrn:dstrato = Comune
it:lombardia:ctrn:nome_asl = CREMONA
it:lombardia:ctrn:nome_com = MOSCAZZANO
it:lombardia:ctrn:nome_pro = CREMONA
it:lombardia:ctrn:nome_reg = LOMBARDIA
it:lombardia:ctrn:perimeter = 19115.05364
it:lombardia:ctrn:sig_pro = CR
it:lombardia:ctrn:strato_ctr = CO
name:left = Ripalta Guerina
name:right = Moscazzano
__

alcuni tags hanno senso, ma un identificativo istat non è per esempio
un tag specifico per la Lombardia. A cosa serve un perimetro, poi in
precisione assurda ( 0.00 mm)? Cosa significa it:lombardia:ctrn:area
= 0.0 ? Cosa identifica il codice ISTAT, questo way o una delle aree
che delimita? Dove si trova la documentazione? Invece mancanno i dati
che interessano: Da quando sono questi dati?. Come mi devo
comportare se correggo un oggetto del genere? Devo modificare la
lunghezza del perimetro?

ciao,
Martin

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione sabas88

Il giorno 22 novembre 2011 11:29, Federico Cozzi f.co...@gmail.com ha
scritto:

 2011/11/22 Martin Koppenhoefer dieterdre...@gmail.com:
  vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se
  chi importa dati da ctr si tiene un database a parte dove si memorizza
  quale entità osm è correllato a quale oggetto / livello della ctr?

 Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non
 importarlo.
 Se invece permette di correlare gli oggetti OSM con gli oggetti CTR,
 allora va importato in OSM perché è l'unico posto che può mantenere
 memoria della correlazione (gli ID di OSM possono cambiare ad es. con
 split/merge di way, e quindi non sono una buona chiave primaria)

 Ciao


 Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire
alla fonte?  Così facendo probabilmente i dati non si evolvono perchè
rimangono legati a come erano in origine. Così l'ho pensata,
Stefano
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione Federico Cozzi

2011/11/22 sabas88 saba...@gmail.com:
 Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire alla
 fonte?

Supponiamo che la Lombardia ci dia i dati aggiornati, e supponiamo
anche (estrema fortuna) che conservino gli ID. Potremmo ipotizzare di
aggiornare i dati già importati con i nuovi dati.

Ciao

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011/11/22 Federico Cozzi f.co...@gmail.com:
 2011/11/22 sabas88 saba...@gmail.com:
 Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire alla
 fonte?
 Supponiamo che la Lombardia ci dia i dati aggiornati, e supponiamo
 anche (estrema fortuna) che conservino gli ID. Potremmo ipotizzare di
 aggiornare i dati già importati con i nuovi dati.


Nel caso dove noi non abbiamo toccato un way di solito dovrebbe aver
mantenuto il suo ID osm e nel caso che noi abbiamo modificato un way
vorrei mantenere il nostro way modificato, non quello del CTR
aggiornato.

In una ipotesi teorica potrei imaginare che noi per la nostra
organizzazione dei dati abbiamo spezzato / unito un way (se abbiamo
potuto unire probabilmente il dato originale non era ottimo) senza
cambiare effettivamente qualcosa. Comunque per capirlo dovresti vedere
la versione di ogni nodo contenuto nel way e paragonarla alla versione
che aveva quando il way è stato creato.

Out of curiosity: ma i CTR, vanno fatto in un modo che gli oggetti si
mantegono la loro ID da una versione all'altra?

ciao,
Martin

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

Re: [Talk-it] Routing trasporti pubblici

2011/11/22 Federico Cozzi f.co...@gmail.com:
 2011/11/22 Luca Delucchi lucadel...@gmail.com:
 beh direi che con pgrouting [0] lo puoi fareperò ti devi creare te
 le regole per il routing

 Il routing dei mezzi pubblici si appoggia principalmente sulle tabelle
 degli orari, le informazioni geografiche sono secondarie. Secondo me
 pgrouting non è l'approccio migliore


+1, se non hai tutti gli orari (che di solito contengono anche migliai
di eccezioni come secondo sabatò del mese ecc.)  è impossibile fare
un buon routing del trasporto pubblico.

ciao,
Martin

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

[Talk-it] R: Routing trasporti pubblici

Il routing del trasporto pubblico era una possibilità di Googlemaps, qualche
anno fa.
(almeno a Firenze. Forse un limitato beta-test ? )
Ora è scomparso da tempo : magari la comunità della mappa libera ha PIU'
possibilità 
del celebre motore ?


-Messaggio originale-
Da: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Inviato: martedì 22 novembre 2011 13.58
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Routing trasporti pubblici

2011/11/22 Federico Cozzi f.co...@gmail.com:
 2011/11/22 Luca Delucchi lucadel...@gmail.com:
 beh direi che con pgrouting [0] lo puoi fareperò ti devi creare 
 te le regole per il routing

 Il routing dei mezzi pubblici si appoggia principalmente sulle tabelle 
 degli orari, le informazioni geografiche sono secondarie. Secondo me 
 pgrouting non è l'approccio migliore


+1, se non hai tutti gli orari (che di solito contengono anche migliai
di eccezioni come secondo sabatò del mese ecc.)  è impossibile fare un
buon routing del trasporto pubblico.

ciao,
Martin

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


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

Re: [Talk-it] R: Routing trasporti pubblici

2011-11-22 Per discussione Federico Cozzi

2011/11/22 Alech OSM alech.hos...@gmail.com:
 Ora è scomparso da tempo : magari la comunità della mappa libera ha PIU'
 possibilità
 del celebre motore ?

L'ingrediente fondamentale sono gli orari: se non hai questi dati
http://code.google.com/intl/it-IT/transit/spec/transit_feed_specification.html
puoi fare ben poco

Qui le città italiane attualmente disponibili su Google Transit:
http://maps.google.it/intl/it/landing/transit/text.html#eu

Ciao

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

Re: [Talk-it] R: Routing trasporti pubblici

2011-11-22 Per discussione Vezzo

È tuttora possibile attraverso i dati gtfs che aziende di trasporto
pubblico forniscono a google. Ad esempio Brescia e Torino li stanno
importando in OSM (solo fermate e percorsi).
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] [osmosis] inclusione di tutte le way in un bbox

2011-11-22 Per discussione emmexx

Ho un problema nell'utilizzo di Osmosis per ricavare i dati contenuti in
un bounding box.

Ho bisogno che vengano incluse nel risultato anche way che siano al di
fuori del bbox ma che intersechino way parzialmente incluse nel bbox.

Faccio un esempio:

osmosis --read-xml file=milano.osm --bounding-box
top=45.49309000 left=9.20749000
bottom=45.47772000 right=9.22966000
completeRelations=yes --write-xml file=m.osm

Il file osm di partenza e' quello che contiene i dati di milano.
Il bounding box e' un rettangolo all'interno del confine comunale.
Una delle way incluse parzialmente nel bbox e' quella con id=28684664 [1]

C'e' un modo per dire ad osmosis di includere anche una way [2]
che e' fuori dal bbox ma interseca la [1]?

Va bene anche una soluzione diversa da osmosis.

grazie
maxx


[1] http://www.openstreetmap.org/browse/way/28684664
[2] http://www.openstreetmap.org/browse/way/23157897

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

Re: [Talk-it] R: Routing trasporti pubblici

2011-11-22 Per discussione Maurizio Napolitano

2011/11/22 Alech OSM alech.hos...@gmail.com:
 Il routing del trasporto pubblico era una possibilità di Googlemaps, qualche
 anno fa.
 (almeno a Firenze. Forse un limitato beta-test ? )
 Ora è scomparso da tempo : magari la comunità della mappa libera ha PIU'
 possibilità
 del celebre motore ?


La risposta e' gia' stata data :)
OpenTripPlanner

Consiglio di leggere poi questa
http://wiki.openstreetmap.org/wiki/Routing

dove, tra l'altro, ho trovato
http://wiki.openstreetmap.org/wiki/Train_routing
http://wiki.openstreetmap.org/wiki/Rollstuhlfahrer-Routing

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione niubii

Il giorno 22 novembre 2011 10:25, Martin Koppenhoefer 
dieterdre...@gmail.com ha scritto:

 Come da oggetto: la Lombardia sta messo bene nella competizione per la
 chiave più lunga.



... è inutile: noi meridionali siamo veramente indietro di quarant'anni,
anche su queste cose...





:-)

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

Re: [Talk-it] Mapping Party Foggia

2011-11-22 Per discussione niubii

Ciao Maurizio,
mi segnalano queste alternative, tutte con wifi libero:

- Caffè Duetto in Corso Garibaldi (isola pedonale, a 1Km. a piedi da
stazione);
- galleria Mongolfiera (molto lontana dalla stazione FF.SS.)
- città del cinema (ancora più lontana).

Ci sarebbe anche il McDonald presso la stazione FF.SS. ma non mi hanno
confermato la presenza del wifi libero.

A me il caffè Duetto sembra una buona soluzione.

Cerco di passare per chiedere info, ma non credo di riuscire entro domani.
In alternativa, se c'e' qualcuno di GFOSS che si è spostato a Foggia ed ha
un attimo di tempo...

Ciao
/niubii/



Il giorno 21 novembre 2011 11:39, Maurizio Marrese 
maurizio.marr...@gmail.com ha scritto:

 Se mi date tempo,
 Provo a trovare qualcosa io
 Che sono di foggia.

 Maurizio Marrese




 E-mail inviata da telefono Android
 (quindi scusate eventuali errori di battitura etc.)
 Il giorno 21/nov/2011 07:51, niubii f.pelu...@gmail.com ha scritto:

 Ci sono novità in merito al locale da utilizzare per il mapping party?

 Ciao
 /niubii/


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


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


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

Re: [Talk-it] Mapping Party Foggia

2011-11-22 Per discussione Maurizio Marrese

confermo,
io stavo cercando...
ma in effetti ci sono queste opzione
se non erro anche il Bar Atzori in via Gramsci,
ma è anche lontano dalla stazione.

Potremmo chiedere all'Università che fra l'altro organizza il GFOSS...

a dopo,
Maurizio







2011/11/22 niubii f.pelu...@gmail.com

 Ciao Maurizio,
 mi segnalano queste alternative, tutte con wifi libero:

 - Caffè Duetto in Corso Garibaldi (isola pedonale, a 1Km. a piedi da
 stazione);
 - galleria Mongolfiera (molto lontana dalla stazione FF.SS.)
 - città del cinema (ancora più lontana).

 Ci sarebbe anche il McDonald presso la stazione FF.SS. ma non mi hanno
 confermato la presenza del wifi libero.

 A me il caffè Duetto sembra una buona soluzione.

 Cerco di passare per chiedere info, ma non credo di riuscire entro domani.
 In alternativa, se c'e' qualcuno di GFOSS che si è spostato a Foggia ed ha
 un attimo di tempo...

 Ciao
 /niubii/



 Il giorno 21 novembre 2011 11:39, Maurizio Marrese 
 maurizio.marr...@gmail.com ha scritto:

 Se mi date tempo,

 Provo a trovare qualcosa io
 Che sono di foggia.

 Maurizio Marrese




 E-mail inviata da telefono Android
 (quindi scusate eventuali errori di battitura etc.)
 Il giorno 21/nov/2011 07:51, niubii f.pelu...@gmail.com ha scritto:

  Ci sono novità in merito al locale da utilizzare per il mapping party?

 Ciao
 /niubii/


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


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



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


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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

-Original Message-
From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com]
Sent: martedì 22 novembre 2011 10:25
To: openstreetmap list - italiano
Subject: [Talk-it] la Lombardia sta messo bene nella competizione per la
chiave
più lunga

E' pieno di tags del genere:
it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3

Riconosco questo tag ;-)

La parte  it:lombardia:ctrn:Limite_amministrativo_09 serve ad identificare
la fonte come lo strato denominato Limite_amministrativo_09 della Carte
Tecnica Regionale della Regione Lombardia. Forse si poteva abbreviarlo, ma
sarebbe diventato ancora più criptico.

La parte OBJECTID serve per dire che quello è l'identificativo univoco che
il database della Regione Lombardia associa a quell'oggetto. E' veramente
un'informazione utile? Non lo so. Se nelle versioni successive il database
della Regione manterrà gli stessi identificativi si potrebbe pensare di
usarlo per automatizzare l'importazione degli aggiornamenti. Mi sembra che
siano parecchi gli import che hanno mantenuto traccia della correlazione tra
elemento OSM ed elemento sorgente. Se poi questi tag siano mai stati
utilizzati non lo so, forse no. Comunque se ci si pente della loro
importazione si fa anche presto a cancellarli, il processo inverso non è
possibile. Non è un'informazione che può andare sul changeset, perché
riguarda un solo oggetto OSM.

La parte _lista1-3 ha una storia a sè. Quando ho importato i confini, ho
voluto, come credo logico, usare una solo way per tutto il tratto di confine
che separa due comuni. Nel database della regione, in alcuni casi il confine
tra due comuni è  spezzato in diversi segmenti. In questi casi
nell'importarlo ho unito i segmenti in un'unica way, e come valore della
chiave  it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID ho messo tutti
gli ID concatenati in una lista.  In alcuni casi (per fortuna rarissimi) il
confine era talmente spezzettato che la stringa degli ID superava la
lunghezza in caratteri ammessa da OSM. Non ho trovato di meglio da fare che
spezzare l'informazione su più  tag, nel caso che hai citato ho dovuto usare
3 tag distinti per farci stare tutti gli ID. Non ho idea perché questi
confini siano così spezzettati nel database della regione, penso che abbiano
commesso qualche errore di elaborazione.

vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se chi
importa dati da ctr si tiene un database a parte dove si memorizza quale
entità
osm è correllato a quale oggetto / livello della ctr?

Forse si, ma la cosa si complica, io certamente non ho le capacità  per
realizzarlo. Poi questo database esterno andrebbe anche reso accessibile ad
altri utenti che volessero consultarlo. Tieni presente che l'import dei
confini della Lombardia è stato fatto da più persone che hanno operato
indipendentemente. E comunque anche gli ID che OSM associa ad un oggetto
possono cambiare per tanti motivi, per risalire con sicurezza a quello
memorizzato nel database esterno bisognerebbe spulciarsi la history, mica
agevole.

Secondome il tag da usare in osm è
boundary=administrative
admin_level=x

Si, quelli ci sono comunque.

Ciao,
Alberto

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

Se proprio si vogliono togliere i tag che si riferiscono al database
sorgente, o rinominarli in forma più abbreviata, si fa abbastanza presto.

 

Ma non capisco cosa intendi per import fatto senza un minimo di
elaborazione. Cosa si sarebbe dovuto fare che non si è fatto?

 

Se per standard esistente intendi luso delle relazioni multipoligono, i
confini ISTAT non li usano perché allepoca dellimportazione non
esistevano. Gli import della Lombardia (e credo anche di tutte le altre
regioni italiane) hanno mantenuto limpostazione originaria ISTAT, non è
attuale ma almeno è uniforme in tutta Italia.

 

Ciao,

Alberto 

 

From: sabas88 [mailto:saba...@gmail.com] 
Sent: martedì 22 novembre 2011 10:29
To: openstreetmap list - italiano
Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per la
chiave più lunga

 

Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo? :)

No, scherzi a parte, mi sembra che sia un import senza un minimo di
elaborazione, come i confini istat che hanno chiavi simili a quella,
bisognerebbe toglierli ed usare lo standard esistente.

Ciao,
Stefano

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1873 / Virus Database: 2101/4632 - Release Date: 11/22/11

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

-Original Message-
From: Federico Cozzi [mailto:f.co...@gmail.com]
Sent: martedì 22 novembre 2011 11:30
To: openstreetmap list - italiano
Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per
la
chiave più lunga

Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non
importarlo.
Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora
va
importato in OSM perché è l'unico posto che può mantenere memoria della
correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way,
e
quindi non sono una buona chiave primaria)

Si, è proprio quello il motivo per cui è stato importato. 

Ciao,
Alberto

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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga

2011-11-22 Per discussione sabas88

Nei confini che ho importato io ci sono solo i tag standard, questi
sembrano presi dal file del ctr e piazzati là :D

Il giorno 22 novembre 2011 22:01, Alberto Nogaro bartosom...@yahoo.it ha
scritto:

 Se proprio si vogliono togliere i tag che si riferiscono al database
 sorgente, o rinominarli in forma più abbreviata, si fa abbastanza presto.*
 ***

 ** **

 Ma non capisco cosa intendi per “import fatto senza un minimo di
 elaborazione”. Cosa si sarebbe dovuto fare che non si è fatto?

 ** **

 Se per standard esistente intendi l’uso delle relazioni multipoligono, i
 confini ISTAT non li usano perché all’epoca dell’importazione non
 esistevano. Gli import della Lombardia (e credo anche di tutte le altre
 regioni italiane) hanno mantenuto l’impostazione originaria ISTAT, non è
 attuale ma almeno è uniforme in tutta Italia.

 ** **

 Ciao,

 Alberto 

 ** **

 *From:* sabas88 [mailto:saba...@gmail.com]
 *Sent:* martedì 22 novembre 2011 10:29

 *To:* openstreetmap list - ital
 iano
 *Subject:* Re: [Talk-it] la Lombardia sta messo bene nella competizione
 per la chiave più lunga

 ** **

 Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo?
 :)

 No, scherzi a parte, mi sembra che sia un import senza un minimo di
 elaborazione, come i confini istat che hanno chiavi simili a quella,
 bisognerebbe toglierli ed usare lo standard esistente.

 Ciao,
 Stefano
 --

 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2012.0.1873 / Virus Database: 2101/4632 - Release Date: 11/22/11*
 ***

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


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

Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga