Re: [Talk-de] Mapnik-Kacheln
Hallo Markus, genau das Phänomen stelle ich auch gerade fest. Also, die ersten Aufrufe laufen flüssig und je mehr man navigiert wird's immer langsamer - bis am Ende gar nix mehr kommt. Versuche gerade inne Firma die Leute von OSM zu überzeugen. Hab auf der OpenLayers-Karte jetzt schnell noch ein paar Google-Layer hinzugefügt, damit der ShowCase am Ende nicht nach hinten losgeht. Gruß, Carsten. osm2po.de Am 19.09.2011 00:30, schrieb Markus: Hallo Holger, ping /t tile.openstreetmap.org liefert bei mit Zeiten von 29..31 ms (min 28ms, max 68ms, med 30ms, verloren 0,4%) was ist TTL? bei mir: TTL=53 Hallo Rolf, ja, eine generelle Netzüberlastung (Wahlen) wäre eine mögliche Ursache. Ich habe aber den Eindruck, dass die Kacheln beim ersten Aufruf wesentlich flüssiger geladen werden, und die Ladehemmung zunimmt bei häufigem Scrollen. Gruss, Markus ___ 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] neues OpenLayers-Buch
Hallo Jan, vorab: Nein, habe das neue Buch auch noch nicht gesehen. Habe aber das alte von der OpenSource-Press von Marc Jansen und Till Adams. War eine echte Enttäuschung. Wenig Neues über OpenLayers und im Kern nur eine Ansammlung von abgegriffenen GIS-Themen. Würde mich also ebenso interessieren, ob sich zu dem Thema endlich einmal ein komplettes Buch gesellt. Gruß, Carsten. Am 30.05.2011 11:25, schrieb Jan Tappenbeck: hi ! in der neusten Wochennotiz wurde von dem neuen engl. Buch zu OpenLayers [1] gesprochen. Hat das schon einer und ist es auch dann noch lohnenswert wenn man das deutschsprachige Buch hat ?? Gruß Jan .-) [1] http://www.amazon.de/dp/1849514127?tag=gismanagementhomlink_code=as2creativeASIN=1849514127creative=9398camp=2514 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] U-Turn via einen Way
Am 07.03.2011 19:08, schrieb M∡rtin Koppenhoefer: Am 7. März 2011 17:42 schrieb Georg Fedderno...@bavarianmallet.de: M∡rtin Koppenhoefer schrieb: wenn das Umkehren auf dem Way verboten ist entspricht das doch einem Wendeverbot, man bräuchte also eigentlich gar keine Relation. jetzt steh ich auf dem Schlauch? :-\ Wie willst Du das Wendeverbot bei getrennten Fahrbahnen angeben, die ja unabhängig voneinander als 2 ways gemappt sind? nein, es geht um die Verbindung zwischen den beiden, die ein Way ist. Bei getrennten Fahrbahnen muss man gar nichts machen, das sind ja sowieso Einbahnstraßen. Eigentlich geht es mir darum, dass via als Node immer ausreicht, soweit ich das im Moment überblicke. Wenn es doch Stellen gibt, wo es ein way sein muss, dann würde mich das interessieren. Der way macht m.E. Probleme, wenn man ihn danach nochmal weiter aufsplitten muss (oder man hat dann halt mehrere Via-Wege). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Stimme dem zu. Und dies aus rein pragmatischen Gründen. Würde sogar noch weiter gehen wollen und alles ausser FromWay-ViaNode-ToWay verbieten. Dabei ist es uebrigens Hupe, welche Art von Restriktion herrscht, also ob links, rechts, unten, oben oder auf dem Mond. Entscheidend ist ob's No- oder Only-Turn ist. Links und rechts und so bilden zwar die Schilder ab, jedoch wirds bei mehr als vier Strassen an einer Kreuzung unlogisch. Ein Routing-Segmenter kommt, wenn ueberhaupt, kaum mit den ViaWays klar. Gruß Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Pbf 4 Gig Java - Problem schon irgendwo gelöst?
Hallo Tekkis, hat sich da seit Dezember schon irgendwo eine Lösung des Problems ergeben? Hab das nämlich gerade selbst bei der aktuellen europe.osm.pbf. Knickt einfach nach ein paar zu viel Knoten ein. Einfach so. Ohne Fehlermeldung. Keine Ways, keine Relationen. Umgebung: Windows XP. Original-Sourcen von crosby.binary... Projekt : Eigenbau. Kleinere Dateien z.B. germany.osm.pbf kein Problem. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pbf 4 Gig Java - Problem schon irgendwo gelöst?
Am 01.05.2011 22:08, schrieb Henning Scholland: Ist in osmosis 0.39 gefixt. Bevor ich jetzt mein SVN bemuehen muss... Eine Idee, was der Grund war? Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pbf 4 Gig Java - Problem schon irgendwo gelöst?
Am 01.05.2011 22:45, schrieb Chris66:
Am 01.05.2011 22:13, schrieb Carsten Moeller:
Am 01.05.2011 22:08, schrieb Henning Scholland:
Ist in osmosis 0.39 gefixt.
Bevor ich jetzt mein SVN bemuehen muss...
Eine Idee, was der Grund war?
Es wurde die 'available' Funktion benutzt, die unter Windows bei
Dateigrößen ab 4 GB anscheinend anders als unter Linux arbeitet.
*int* available()
Returns an *estimate* of the number of bytes that can be read (or
skipped over) from this input stream without blocking by the next
invocation of a method for this input stream.
Fettung von mir (soll verdeutlichen, dass man diese Funktion
bei großen Dateien lieber meiden sollte).
Chris
Vielen Dank, Chris.
Ja ja, ..., available() ... ein guter, böser alter Bekannter ;-)
Hab's auch gerade herausgefunden und gleich eingecheckt.
Jetzt läuft mein Europa ... Gerade bei Knoten Nr. 300 Mio.
... 180 kommen noch. Mal schauen ...
Hier nochmal der Patch:
Index: BlockInputStream.java
===
--- BlockInputStream.java (revision 1065)
+++ BlockInputStream.java (working copy)
@@ -17,6 +17,7 @@
package crosby.binary.file;
+import java.io.EOFException;
import java.io.IOException;
import java.io.InputStream;
@@ -28,10 +29,13 @@
}
public void process() throws IOException {
-while (input.available() 0) {
-FileBlock.process(input, adaptor);
+ try {
+while (true) {
+ FileBlock.process(input, adaptor);
}
+ } catch (EOFException e) {
adaptor.complete();
+ }
}
public void close() throws IOException {
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Planet.osm mit Java BZip2CompressorInputStream und URL.openStream lesen?
Hallo an alle Java-Tekkis!
Hat jemand schon mal versucht, das planet.osm.bz2 direkt in Java
einzulesen? Bei mir bricht das Teil grundsätzlich nach 900.000 Bytes
zusammen. Nix Fehlermeldung - einfach fertig.
Gruß, Carsten.
PS:
Code in etwa so (Schnellschuss):
public static void main(String[] args) throws Exception {
URL url = new URL(
http://ftp.ecki-netz.de/osm/planet-latest.osm.bz2;);
InputStream is = url.openStream();
BZip2CompressorInputStream bz2is = new BZip2CompressorInputStream(is);
OutputStream os = new FileOutputStream(planet.osm);
byte[] buf = new byte[1024];
int bytesRead = bz2is.read(buf);
int i = 0;
// Wir wollen hier nicht alles lesen, 1 loops reichen.
while (i++ 1 bytesRead = 0) {
os.write(buf, 0, bytesRead);
bytesRead = bz2is.read(buf);
}
bz2is.close();
os.close();
}
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu ti...@home Windows
Am 11.01.2011 23:37, schrieb Stephan Knauss: On 11.01.2011 19:52, Carsten Moeller wrote: War jetzt lange nicht mehr am Ball aber schau mal hier: http://wiki.openstreetmap.org/wiki/DE:windowscli...@home warum machst du das alles von Hand? Warum nicht einfach einen Doppelklick auf den Installer? Der installiert alle notwendigen Tools und Erweiterungen, ggf. auch noch Java und rendert mit Batik. Moin, schau mal auf das Datum, von wann die Doku ist. Damals war alles noch ein wenig wackelig. Außerdem hat diese Vorgehensweise auch Vorteile. Z.b. wenn man nicht alles doppelt installieren will, weil u.U. die Pfade verbogen werden u.ä. Ansonsten: Für die Java-Spezies: Java kann auf einer Windows-2Gig-Maschine maximal -Xmx1408m. seltenst. Woran es genau liegt kann ich dir nicht erklären, die Grenze liegt meist niedriger. 1350 hat meist funktioniert. Machmal können die Systeme auch weniger. Es gibt einen dokumentierten Fall bei dem die Comodo Firewall dafür gesorgt hatte dass die Grenze niedriger war. Stephan Denke, das liegt dann aber nicht an Java, sondern daran, dass hier der o.g. Prozess bereits vorher das RAM geklaut hat. Java auf 32Bit-Maschinen unter Windows kann 1408. Tausendmal ausprobiert. Höher geht aber witzigerweise nicht. Auch wenn die Kiste mehr als 2 Gig hat. Das ist dann ein pures Windows-Problem. Linux kommt bei einigen Derivaten auf 2Gig. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu ti...@home Windows
Am 06.01.2011 23:29, schrieb Rainer Knaepper:
Moin,
nachdem ich nun einen Rechner mit Quadcore habe, dachte ich mir, ich
opfere einen davon für ti...@home.
Es funktioniert aber nicht.
Windows XP SP3, 2GB Ram, Plattenplatz genügend. Installation per
http://wiki.openstreetmap.org/wiki/wind...@home#tiles.40home_for_windows_installer
Einen Auszug aus dem Konsolenfenster kann ich bieten:
- Using working directory C:\TilesAtHome\tmp
! 'flock' not available. Do not run concurrent uploads
- Pngcrush version 1.7.9
- pngnq version 0.5
- Java version 1.6 is available
- rendering using or/p
This is version 23290 (Vizag) of tilesgen running on MSWin32, ID: 1809
Use of uninitialized value $ENV{PROGRAMFILES(X86)} in concatenation (.) or str
ing at lib/SVG/Rasterize/Engine/Batik.pm line 101.
- rasterizing using SVG::Rasterize::Engine::Batik
batikpath: no such variable
[#2 0% ] Tileset (12,2174,1463) around 45.61,11.12 complexity 1787438 priority
2
[#2 0% tile-z12] Rasterizing failed with runtime exception: Error running C:\
WINDOWS\system32\java.exe: exited with value 1 at lib/SVG/Rasterize/Engine/Bati
k.pm line 338.
[#2 0% tile-z12] Putting job (12,2174,1463) back due to 'Exception in RenderSV
G: Error running C:\WINDOWS\system32\java.exe: exited with value 1'
Use of uninitialized value in concatenation (.) or string at tilesGen.pl line 78
Hallo Rainer,
du benutzt Batik?
Also, wenn das klappt, ist was passiert. Dann werde ich auch mal wieder
meine Kiste auf t...@h loslassen.
Bin ja kein Freund von Inkscape. Sei's drum.
War jetzt lange nicht mehr am Ball aber schau mal hier:
http://wiki.openstreetmap.org/wiki/DE:windowscli...@home
(Stammt von mir, ist aber schon uralt)
Ansonsten: Für die Java-Spezies: Java kann auf einer
Windows-2Gig-Maschine maximal -Xmx1408m.
Gruß,
Carsten
3.
Use of uninitialized value in string eq at tilesGen.pl line 784.
[#2 0% tile-z12] Warning: used uninitialized fault
[#2 0% tile-z12] Exception in RenderSVG: Error running C:\WINDOWS\system32\ja
va.exe: exited with value 1
[#2 0% tile-z12] Waiting before new tile is requested. Idle for 15 (Total 0:00
Die GUI meldet:
Rasterize command: C:\WINDOWS\system32\java.exe, -Xms256M, -
Xmx1350M, -classpath,
c:\tilesAtHome\batik\xercesImpl.jar;c:\tilesAtHome\batik\batik.jar,
org.apache.batik.apps.rasterizer.Main, -scriptSecurityOff, -w,
256, -h, 256, -a, 0.00,0.00,878.906250,878.906250,
-d, C:\TilesAtHome\tmp\12_2229_1573_0e5_o\tile-z12-s0.png,
C:\TilesAtHome\tmp\12_2229_1573_0e5_o\tile-z12.svg
Rasterize engine STDOUT:Error occurred during initialization of VM
Could not reserve enough space for object heap
Rasterize engine STDERR:Could not create the Java virtual machine.
Der Windoof-Taskmanager behauptet, es seien 1.2 GB Ram verfügbar. Eine
andere Java-Anwendung, die ich hier habe, läuft fehlerfrei.
Sehe ich das richtig, daß ti...@home gerne 256 + 1350 MB Ram hätte?
Oder liegt der Fehler woanders?
Rainer
--
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Integer-Ueberlauf von IDs - Wann zu erwarten?
Am 20.12.2010 22:56, schrieb Heiko Jacobs: Am 20.12.2010 15:03, schrieb Florian Lohoff: Ich denke das mit den 7 nachkommastellen wird irgendwann fallen. Es gibt ja reichlich leute die es geil finden straßen als flaechen zu mappen und dann kommen wir irgendwann in den bereich wo durch rundungsfehler dann komische flaechen bei rauskommen. *kopfkratz* 1° = 40.000.000 / 360 m -- * 0.001 = 0.011 m 7 Nachkommastellen == cm-Genauigkeit. Wo da groß Rundungsprobleme sein sollen ... Gruß Mueck Hi Mueck, dies ist auch meine Meinung. Wo OSM noch hin will ist mir bei all den Kommentaren (auch weiter unten) nicht mehr ganz klar. Anscheinend will man tatsächlich irgendwann mal in der Lage sein, Mikrobenmapping zu betreiben. Also wenn wir heute schon in Lage sind, Ameisennesteingänge auf einem Ameisenhaufen genauestens zu bestimmen, und dies unter der Annahme, dass die Ameisenverordnung besagt, dass Ameisenhauseingänge nicht dichter als zwei Ameisenlängen nebenaneinander angelegt werden dürfen, dann könnte es in OSM ernsthafte Probleme geben ;-) OK, was durchaus irgendwann Sinn machen könnte, wäre die dritte Dimension. Allerdings könnte man dies datenseitig auch anders abbilden. Im Hintergrund sehe ich aber immer wieder diverse Anwendungen (auch meine eigene) die irgendwann in ihrer Performance und dem Speicherverbrauch in die Knie gehen werden, wenn die Bitfresserei Überhand nimmt. Gruß, CARSTEN ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Integer-Ueberlauf von IDs - Wann zu erwarten?
Am 20.12.2010 21:15, schrieb Schlauchboot: Hier muss ich mir mal selbst widersprechen. Die Schätzung von 33 Jahren setzt u.A. voraus, daß sich die Verdoppelung pro Jahr fortsetzen wird. Bei 33 Jahren ist das nicht nur gewagt sondern sehr wahrscheinlich falsch. Die Oberfläche der Erde beträgt 4 * PI * R^2, mit R ~ 6375 km. Node-IDs hat man 2^63. Daraus folgt durch Division: 2^63 / Erdoberfläche = 1,8 Nodes pro cm^2. Das ist schon recht ambitioniert. Wenn man dann noch berücksichtigt, daß die Erdoberfläche zu 2/3 aus Wasser besteht, also aus recht langweiliger Gegend, dann sollten die Node-IDs schon sehr weit reichen. Ggf. wird dann wohl doch ein Reorg die Qual der Wahl sein, wobei man dabei u.U. die ältere History wegschmeissen kann. Der Grafik aus OSM nach zu Urteilen (Dank an Jochen) ist meiner Meinung nach auch keine Verdopplung zu erwarten. Ich sehe da eher sowas wie 250 Mio IDs pro Jahr. Auch wenn vielleicht ein paar Dussel 'n paar Fehlimporte starten, dürfte ein WorstCase gefühlt bei 500 Mio pro Jahr zu erwarten sein. Kann mir auch nicht vorstellen, dass, wenn erstmal was getaggt ist, da noch zu häufig dran rumgebastelt wird. Offensichtlich sind's zur Zeit wohl eher die Fremdimporte oder das Gebäudemapping. Diese Sachen dürften wohl a) zu unterbinden sein und b) sich irgendwann sättigen. Dass jetzt plötzlich alle Chinesen auf die Idee kommen mit 'nem Navi durch die Reisfelder zu geistern, halte ich für ausgeschlossen. Gruß, CARSTEN ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Integer-Ueberlauf von IDs - Wann zu erwarten?
Hallo Tekkis! Obwohl intern ja bereits auf LONG-Integer umgestellt wurde, würde mich trotzdem mal interessieren, wie groß die derzeit höchste Node-ID ist und wann mit einem Integer-Ueberlauf zu rechnen ist. Ferner interessiert mich auch die Geschwindigkeit, mit der diese IDs wachsen. 1 Gig pro Jahr oder doch wesentlich langsamer? Die WayIDs haben ja innerhalb des Integer-Bereichs noch ein wenig Platz. Oder liege ich hier falsch? Gruß an alle Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Integer-Ueberlauf von IDs - Wann zu erwarten?
VIELEN DANK an alle für die nützlichen Infos. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Integer-Ueberlauf von IDs - Wann zu erwarten?
Am 19.12.2010 18:55, schrieb Chris66: Am 19.12.2010 16:55, schrieb Wolfgang: Na, wenn da solche Lücken drin sind, lohnt es sich ein 1-2 Jahren mal, ein script zu schreiben, dass den ganzen Kram wieder zusammenschiebt. Dann muss man die Historie aber wohl resetten oder? Alternative: Die IDs von gelöschten Nodes für neue Nodes wiederverwenden. Chris Hallo Chris, die Geschichte läuft auf einer Postgres-Sequenz (AutoIncrement). Da irgendwie dazwischen zu kommen, dürfte schwer werden. Das ganze irgendwann einmal zusammenzudampfen, halte ich für den gängigeren Weg. Allerdings dürfte bei einem Long-Integer erstmal für einige Dekaden Luft nach oben sein, trotz irgendwelcher Tölpel, die mal eben 100.000 Knoten einfügen, um sie dann wieder zu löschen. Interessanterweise wird auf der OSM-Hauptseite immer noch von einem 32-Bit-Integer gesprochen. Im Übrigen genau so von maximal 7 Nachkommastellen für LatLon. Der 32-Bitter hat sich ja nun bald erledigt. Spannender finde ich die 7 Nachkommastellen. Diese lassen sich nämlich auch in 64-Bit darstellen (LatLon). Somit benötigt ein Knoten eigentlich gar keine ID, es sei denn, man möchte Briefkasten und Briefkastenschlitz mit unterschiedlichen IDs taggen. Wär mal 'ne Überlegung wert. Gruß, CARSTEN ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 10.11.2010 01:18, schrieb Garry: Hallo Carsten, Am 07.11.2010 15:00, schrieb Carsten Moeller: Hallo Garry, da gibt es so'n tag namens access=destination, was zwar im Deutschen als Anlieger frei übersetzt wird, meines Erachtens im Englischen als auch Allgemeinen durchaus eine andere Interpretation zulassen würde. Was ist Deine Meinung hierzu? Nach http://wiki.openstreetmap.org/wiki/DE:Key:access wären hier auch Fussgänger ausgesperrt, es müsste also heissen vehicle=destination. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Natürlich muss man dann natürlich unterscheiden. Bezog sich jetzt im allgemeinen auf alle access-Unterkategorien. Wichtig ist mir hier die Frage nach der Interpretation und Bedeutung von destination. Und dies auch in anders-deutsch-sprachigen Regionen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 23:03, schrieb Garry: Am 04.11.2010 22:37, schrieb Chris66: Am 04.11.2010 22:14, schrieb Garry: Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Genau. Siehe Zu- und Abfahrten zu Autobahnraststätten, die meist auch als service getaggt sind. Bin zwar kein Routerprogrammierer, aber einen Check ob eine service-Road mit einer route=ferry verbunden ist (um sie für's Routing intern höher zu stufen) stelle ich mir nicht schwierig vor. Wenn Du Dir gezielt dafür einen service-weg herauspickst sicher nicht. Nur musst Du in so einem Fall aber hunderte oder gar tausende von service untersuchen die in einem Korridor zwischen Start und Zielpunkt liegen und eventuell nur mit einer niederwertigeren Strasse an die Hauptadern angeschlossen sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Nur eine kleine Zusatzinfo, um diese Aussage noch zu untermauern. Kommt ein bisschen spät und ist jetzt mitten im Thread gelandet, wusste aber nicht, wo es sonst besser passen könnte. Habe mal Deutschland (atkuelle germany.osm) berechnet und die Services dabei berücksichtigt. Access-Tags wie motorcar=no oder private und so sind da bereits mit berücksichtigt - bzw. um diese reduziert. Nach der Segmentierung stoße ich auf folgende Zahl an Service-Weg-Segmenten (bidirektional): 1.191.982 (in Worten: EinsKommaEinsNeun Millionen!!!) Dies ist die Zahl an Wegen, die ein Router zusätzlich untersuchen muss, damit er über die o.g. Sonderlocken routen kann. Zum Vergleich die wenigen Autobahnen (ohne links): 39.636 (in Worten rund : VierzigTausend!!) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hallo Aighes, nein, nur grob reduziert. Könnte das aber mal testen. Hast du da noch so'n paar von der Sorte auf Ex in Petto? Ich sehe da z.B. noch driveway, emergency_access oder drive-through. Ich sach ma so: Wenn man den ganzen Service-Schlonz, der wirklich nur zur Milchkanne führt so begrenzen könnte, würde das die Menge erheblich reduzieren. Ich bin also noch optimistisch. Gefühlt würde ich jetzt mal sagen, so bis 200.000 könnte das schon wieder einigermaßen erträglich werden. Parallel denke ich gerade über eine Mischform aus menschlicher Mustererkennung und Rohdaten nach. So'ne Art Critical-Region-Editor oder so..., wo dann bestimmte Dinge einfach genauer betrachtet werden. Hätte auch den psychologischen Vorteil, dass sich hier ein Mensch dem Computer überlegen fühlen darf. ;-) Gruß, CM ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 13:05, schrieb Garry: Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Ich denke je mehr man da berücksichtigen muss um so weniger lohnt sich der Aufwand des herausrechnens. Und unter Umständen muss man dann auch noch auf Kombinationen achten die sich Gegenseitig aufheben oder nur in Kombination Sinn machen... Ganz schön viel Aufwand für die Vergleichsweise sehr geringe Anzahl an Fähr- und Autozugverbindungen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Garry, da gibt es so'n tag namens access=destination, was zwar im Deutschen als Anlieger frei übersetzt wird, meines Erachtens im Englischen als auch Allgemeinen durchaus eine andere Interpretation zulassen würde. Was ist Deine Meinung hierzu? Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 14:59, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: 1.191.982 (in Worten: EinsKommaEinsNeun Millionen!!!) Dies ist die Zahl an Wegen, die ein Router zusätzlich untersuchen muss, damit er über die o.g. Sonderlocken routen kann. Das ist doch aber nur dann problematisch, wenn man einen mangelhaften (oder sagen wir mal: einen altertuemlichen) Algorithmus verwendet. Ein moderner, optimierter Algorithmus a la Contraction Hierarchies steckt das locker weg - siehe z.B. Monav, das selbst auf einem schwachbruestigen Mobilprozessor in Bruchteilen einer Sekunde quer durch Europa routet. Bye Frederik Hallo Frederik, das klingt auf jeden Fall spannend. Druck mir gerade mal eine Diplomarbeit ausm Netz dazu aus und werde das gleich mal studieren. So weit ich ich das in der Kürze überblicke, beschäftigt sich das Thema sehr viel mit der Thematik der Reduktion von Informationen, bzw. dem Multilevel. Sowas ähnliches habe ich bei mir auch eingebaut. Von Lissabon nach Moskau benötigt meine Kiste derzeit ca. 3 Sekunden. Das allerdings auch nur unter Verwendung bestimmter Annahmen. z.B. Multilevel und so. Aber ich will mich da jetzt nicht zu weit aus dem Fenster lehnen. Erstmal lesen, was da so alles steht. Vielleicht bin ich hinterher ja schlauer, was durchaus kein Nachteil wäre ;-) Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hab jetzt mal 'n bisschen mehr ausgeklammert. Komme jetzt auf: 754.631 Gefühlt: Immer noch zu viele! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 17:04, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Bye Frederik Hmmm... ich hab jetzt in der Kürze der Zeit noch nicht viel darüber gelesen... Hätte da aber mal ein paar Kernfragen, da du ja an der Quelle sitzt. (Die Fragen beziehen sich auf einen herkömmlichen, etwas älteren Rechner mit sagen wir mal 2 Gig RAM, und ein paar Herz Taktgeschwindigkeit OHNE VM) a) Ist ein Preprocessing über europe.osm möglich - Wie lange dauert sowas? b) Werden OneWays berücksichtigt? c) Sind die Turning-Restrictions mit drin? d) Bevor ich jetzt lange suche: Gibt's einen Link zu der OpenSource-Bibliothek? Gruß und vorab schon mal -Danke für die Infos- Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 07.11.2010 18:59, schrieb Carsten Moeller: Am 07.11.2010 17:04, schrieb Frederik Ramm: Hallo, Carsten Moeller wrote: Weißt Du zufällig, ob das schon mal jemand auf OSM-Daten losgelassen hat? Ja, klar, beim Monav ist das doch alles schon dabei, inkl. Datenaufbereitung und so (schau mal auf die routing-Liste). Die standalone-Version des Algorithmus gibt es auch als Open Source, und eine Demo ist auf routingdemo.geofabrik.de zu sehen (derzeit mit einem aelteren Daten-Ausschnitt fuer Westeuropa - das ist eine VM mit 2 GB RAM, da geht ganz Europa nicht drauf). Bye Frederik Hmmm... ich hab jetzt in der Kürze der Zeit noch nicht viel darüber gelesen... Hätte da aber mal ein paar Kernfragen, da du ja an der Quelle sitzt. (Die Fragen beziehen sich auf einen herkömmlichen, etwas älteren Rechner mit sagen wir mal 2 Gig RAM, und ein paar Herz Taktgeschwindigkeit OHNE VM) a) Ist ein Preprocessing über europe.osm möglich - Wie lange dauert sowas? b) Werden OneWays berücksichtigt? c) Sind die Turning-Restrictions mit drin? d) Bevor ich jetzt lange suche: Gibt's einen Link zu der OpenSource-Bibliothek? Gruß und vorab schon mal -Danke für die Infos- Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hmmm... Oben: Dijkstra, Unten: Monav. Kann natürlich auch an der Bewertung der Straßen liegen. http://osm2po.de/download.php?dl=cmp.jpg Ich hoffe, es ist zu erkennen, wo das ist. Ansonsten: Hölle schnell das Teil!!! Gruß, CM. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am 06.11.2010 08:07, schrieb Christian Knorr: Hallo zusammen, die letzte mir bekannte AIO Europa (vom 20.10.2010) ist nun zu groß für meine 4GB SD-Card. Ist geplant, dass da in der Hinsicht was verändert werden soll? Oder soll der Funktionsumfang gleich bleiben? Da ich ein Oregon habe, könnte ich freilich auch die Einzelsegmente laden und kopieren, und da was weg lassen, aber bisher war es halt so schön simpel. Ich lade gerade die vom 3.11.2010, wobei ich mir nicht vorstellen kann dass die kleiner ist. MfG, Chris... Hallo Chris, ich hab keine Ahnung (das ist ja eine tolle Einleitung ...;), was da alles in die Karte aufgenommen wird. Anscheinend ja fast alles! Ich sehe mich mit ähnlichen Dingen konfrontiert und will nur ein paar Zahlen für Deutschland liefern. Als ich mich vor einem Jahr mit dem OSM-Routing (hardcore) begann zu beschäftigen, da lieferte mir OSM in etwa 40Mio Knoten. Heute sind's bereits annähernd 60Mio. Und dies eigentlich nur, weil OSM ja nicht zwischen z.B. Gebäuden und Wegen und so trennt. Da ist ein Knoten erstmal ein Knoten. Wenn also der Speicher zu gering ist, egal ob Kiste oder Navi, dann kann man eigentlich nur noch Dinge weglassen, um die Mengen zu reduzieren. Ein weiteres Problem wird es gefühlt in ca. 3 Jahren geben. Dann nämlich wird OSM mit seinen IDs an die 32-Bit-Grenze stoßen - schöpfen heute bereits 31 Bits aus - und sämtliche IDs auf 64-Bit umstellen. Wenn da vorher seitens der Garmins, Router, usw. keine Umschlüsselung stattfindet, dann wird der Speicherbedarf sogar ohne Mehrinformation von heut auf morgen aufgepumpt. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am 06.11.2010 08:46, schrieb Carsten Moeller: Am 06.11.2010 08:07, schrieb Christian Knorr: Hallo zusammen, die letzte mir bekannte AIO Europa (vom 20.10.2010) ist nun zu groß für meine 4GB SD-Card. Ist geplant, dass da in der Hinsicht was verändert werden soll? Oder soll der Funktionsumfang gleich bleiben? Da ich ein Oregon habe, könnte ich freilich auch die Einzelsegmente laden und kopieren, und da was weg lassen, aber bisher war es halt so schön simpel. Ich lade gerade die vom 3.11.2010, wobei ich mir nicht vorstellen kann dass die kleiner ist. MfG, Chris... Hallo Chris, ich hab keine Ahnung (das ist ja eine tolle Einleitung ...;), was da alles in die Karte aufgenommen wird. Anscheinend ja fast alles! Ich sehe mich mit ähnlichen Dingen konfrontiert und will nur ein paar Zahlen für Deutschland liefern. Als ich mich vor einem Jahr mit dem OSM-Routing (hardcore) begann zu beschäftigen, da lieferte mir OSM in etwa 40Mio Knoten. Heute sind's bereits annähernd 60Mio. Und dies eigentlich nur, weil OSM ja nicht zwischen z.B. Gebäuden und Wegen und so trennt. Da ist ein Knoten erstmal ein Knoten. Wenn also der Speicher zu gering ist, egal ob Kiste oder Navi, dann kann man eigentlich nur noch Dinge weglassen, um die Mengen zu reduzieren. Ein weiteres Problem wird es gefühlt in ca. 3 Jahren geben. Dann nämlich wird OSM mit seinen IDs an die 32-Bit-Grenze stoßen - schöpfen heute bereits 31 Bits aus - und sämtliche IDs auf 64-Bit umstellen. Wenn da vorher seitens der Garmins, Router, usw. keine Umschlüsselung stattfindet, dann wird der Speicherbedarf sogar ohne Mehrinformation von heut auf morgen aufgepumpt. Gruß, Carsten Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am 06.11.2010 09:00, schrieb Florian Lohoff: On Sat, Nov 06, 2010 at 08:54:16AM +0100, Carsten Moeller wrote: Carsten Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-) Nur wenn es ein signed int32 waere - isses aber nicht: osm=# \d nodes Table public.nodes Column|Type | Modifiers --+-+--- id | bigint | not null version | integer | not null user_id | integer | not null tstamp | timestamp without time zone | not null changeset_id | bigint | not null geom | geometry| bigint ist schon 64 bittig ... Reicht noch nen bischen. Vielleicht nicht auf dem Garmin - aber OSM kommt noch nen bischen aus ... Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Flo, ja, so weit ich weiß, sind 64 Bit in OSM bereits in Vorbereitung bzw. werden intern bereits verwendet. Wie das vorher in MySQL aussah, weiß ich nicht, jedoch vermute ich, dass mit dem Sprung nach PostGIS auch bereits die 64 Bits aufgenommen wurden. Von einer offiziellen Umstellung habe ich noch nichts mitbekommen. Hab zwar nicht wieder reingeschaut, aber vor kurzem stand im Wiki immer noch IDs sind Integer (32) oder so ähnlich oder ich hab da Tomaten auf den Augen gehabt. Ja, und signed waren die meines Erachtens auch nicht. Es wurden ja negative IDs verwendet, um damit administrative Dinge kenntlich zu machen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Am 06.11.2010 10:22, schrieb Carsten Moeller: Am 06.11.2010 09:00, schrieb Florian Lohoff: On Sat, Nov 06, 2010 at 08:54:16AM +0100, Carsten Moeller wrote: Carsten Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-) Nur wenn es ein signed int32 waere - isses aber nicht: osm=# \d nodes Table public.nodes Column | Type | Modifiers --+-+--- id | bigint | not null version | integer | not null user_id | integer | not null tstamp | timestamp without time zone | not null changeset_id | bigint | not null geom | geometry | bigint ist schon 64 bittig ... Reicht noch nen bischen. Vielleicht nicht auf dem Garmin - aber OSM kommt noch nen bischen aus ... Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Flo, ja, so weit ich weiß, sind 64 Bit in OSM bereits in Vorbereitung bzw. werden intern bereits verwendet. Wie das vorher in MySQL aussah, weiß ich nicht, jedoch vermute ich, dass mit dem Sprung nach PostGIS auch bereits die 64 Bits aufgenommen wurden. Von einer offiziellen Umstellung habe ich noch nichts mitbekommen. Hab zwar nicht wieder reingeschaut, aber vor kurzem stand im Wiki immer noch IDs sind Integer (32) oder so ähnlich oder ich hab da Tomaten auf den Augen gehabt. Ja, und signed waren die meines Erachtens auch nicht. Es wurden ja negative IDs verwendet, um damit administrative Dinge kenntlich zu machen. Gruß, Carsten Korrektur: meinte natürlich unsigned ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 22:37, schrieb Chris66: Am 04.11.2010 22:14, schrieb Garry: Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Genau. Siehe Zu- und Abfahrten zu Autobahnraststätten, die meist auch als service getaggt sind. Bin zwar kein Routerprogrammierer, aber einen Check ob eine service-Road mit einer route=ferry verbunden ist (um sie für's Routing intern höher zu stufen) stelle ich mir nicht schwierig vor. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Chris, und das ist eben der Irrglaube vieler. Das ist genau der Grund, welcher die Router tötet. Dies ist mit einem LookAhead verbunden, der, solange die Datenmenge klein ist, z.B. Städte oder max. Bundesländer, noch einigermaßen performant zu berechnen ist. Im Länder- oder Kontinent-Rahmen ist die Rechenzeit dann unerträglich. Dann kommen Heuristiken ins Spiel. Zu bedenken ist hierbei auch die Tatsache, dass nach einer Ferry ein Service, dann noch ein Service, vielleicht noch ein Service und dann erst ein highway=höher folgt. Um das zu greifen, lohnt es sich kaum noch irgendwas zu betrachten, sondern stattdessen gleich alle Services mit einzubeziehen oder eben auszublenden. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 15:08, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 21:09 schrieb Carsten Moellercmindivid...@gmx.de: Aber es wird doch hier ersichtlich, dass ein einfaches Tag ala service=wichtig die komplette Kuh mit einer einfachen, pragmatischen Aussage vom Eis kriegt. m.E. ist das semantischer Käse. Entweder ist ein Weg eine wichtige (allg.) Verbindung, dann kann er kein service sein, oder er ist eine Sackgasse, die nur zu einem bestimmten Ziel führt, und für alle anderen unwichtig ist, dann ist er ein service. Das ist m.E. gemeint mit service für Zufahrt. Ich verstehe nicht, warum man unbedingt service als Klasse vergeben muss für Wege, die ihrer Natur nach was komplett anderes sind als eine Parkplatzzufahrt oder Grundstücksauffahrt (weil es dahinter im Falle eines Fährhafens eben weitergeht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich will ja nicht behaupten, dass ich das selber toll finde, was ich da geschrieben habe. Man muss nun einmal die Realitäten berücksichtigen; Und die Realität bedeutet, dass unzählige Wege dieser Art bereits mit highway=service getaggt sind. Dann sind da ja noch die unterschiedlichen Meinungen zu diesem Thema. Für die einen ist Service ein Zulieferer oder eine Zufahrt, und dies in jeder Hinsicht. Andere teilen teilweise diese Auffassung, wollen dann aber noch zwischen Zufahrt mit Sackgassen- bzw. Zu-/Überfahrt mit Zubringercharacter trennen. Der nächste argumentiert dann: Das ist dann aber kein Service mehr - Aus Router Sicht ist es dann natürlich kein Service. Aber wir Router können uns das hier leider nicht wünschen und müssen die OSM-Sicht akzeptieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 09:32, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 08:21 schrieb Ulf Lampingulf.lamp...@googlemail.com: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: deshalb sind wir beim letzten Mal schon nicht weitergekommen... Irgendein Wohnzimmer Extremist findet sich halt immer, der die Diskussion hier in die Ergebnislosigkeit führt. Diesmal bist es halt nicht du ;-) Beispiele? Ich gebe zu, dass ich einer der Vielschreiber auf der ML bin, aber ich sehe mich eigentlich nicht als Wohnzimmer Extremist, ich bin durchaus draußen zum mappen, und meine Beiträge hier sind m.E. ergebnisorientiert und entstehen nicht mit dem Ziel der puren Diskussion. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Alle Mann abkühlen!!! Als derjenige, der diesen Thread so zu sagen ein zweites Mal entflammt hat, möchte ich doch sehr bitten! Es muss doch irgend eine Lösung zu finden sein, die beide Welten miteinander vereint. Meine und wahrscheinlich auch die von Ulf, also die Routersicht, und die der Mapper. Die Kernfrage ist doch, was kann ich aus den OSM-Daten machen. Egal ob Routing oder Briefkastensuche. Mir persönlich wichtig ist dabei nur, dass die Daten auch ohne Heuristiken verarbeitbar bleiben und dafür ein herkömmlicher Computer ausreicht. Sonst wird's exklusiv und es werden Abhängigkeiten zu Anbietern geschaffen, die dann irgendwann den Laden zu machen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 13:58, schrieb Peter Wendorff: Alle Mann abkühlen!!! Fieberthermometer sagt 36,7°, ich hoffe, das ist okay ;) Als derjenige, der diesen Thread so zu sagen ein zweites Mal entflammt hat, möchte ich doch sehr bitten! Es muss doch irgend eine Lösung zu finden sein, die beide Welten miteinander vereint. Meine und wahrscheinlich auch die von Ulf, also die Routersicht, und die der Mapper. Die Kernfrage ist doch, was kann ich aus den OSM-Daten machen. Egal ob Routing oder Briefkastensuche. Mir persönlich wichtig ist dabei nur, dass die Daten auch ohne Heuristiken verarbeitbar bleiben und dafür ein herkömmlicher Computer ausreicht. Sonst wird's exklusiv und es werden Abhängigkeiten zu Anbietern geschaffen, die dann irgendwann den Laden zu machen. +1, und einen Vorschlag biete ich gleich dazu: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße, Schiene, oder Wasser müssen nur irgendwie verbunden sein. Dann funktionieren alle Router. Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation). Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist lediglich bei der Aufbereitung der Infos für ein Routing relevant: Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Das Routing-Gewicht dessen lässt sich als ganzes vergeben, die Route ist sowieso festgelegt; und trotzdem können die Details/service-Wege als solche korrekt gemappt werden. Gruß Peter ___ 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] AIO - Routing über Fähren
Am 03.11.2010 15:08, schrieb Peter Wendorff: Am 03.11.2010 14:36, schrieb Carsten Moeller: Am 03.11.2010 13:58, schrieb Peter Wendorff: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße, Schiene, oder Wasser müssen nur irgendwie verbunden sein. Dann funktionieren alle Router. gut ;) Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) Ich rede von einer Relation, ja; und ich halte das nicht für unbeherrschbar, sondern im Gegenteil für eine Vereinfachung des Routings (zumindest des Navigationsgraphen). Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation). Abbiegevorschriften sind was anderes; dabei werden Beschränkungen eingebaut. Abbiegevorschriften sind technisch das Gleiche. Das sind auch nur Relationen mit einer Menge anderer Verweise, in diesem Fall meistens FromWay, ViaNode und ToWay. Ob nun noch zusätzlich ein no_left_turn oder no_right_turn folgt ist Hupe. Eine andere Vorschrift oder Zusatzinfo könnte genau so grün, blau, Weltkulturerbestraße Russland-Atlantis oder eben Fährverbinder heißen. Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als abkürzende Wegstücke eingebaut werden können. Eine Relation vom Typ ferry|car_train, die zwei nodes mit role=entrypoint (völlig willkürlich und nicht über die Formulierung nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1 nach entrypoint2 und Gewicht n betrachten. Abfragen kann man diese Routen recht einfach: Relationen mit type=ferry|car_train abzufragen ist nicht schwieriger als highways mit type=secondary. Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. Ein herkömmlicher Rechner wird dies kaum leisten können, es sei denn er liest den Datenstrom zyklisch so lange, bis alles aufgelöst ist. Eine Datenbank (z.B. PostGIS) ist hier übrigens auch nicht schneller oder besser. Das sind alles Läufe, die nicht mehr in Stunden, sondern im 0,5-Tages-Intervall zu messen sind. Wenn man dafür bei vollständigem tagging die Service-Wege außer acht lassen kann, die ja von den Routing-Fetischisten hier als so böse betrachtet worden sind, finde ich, ist das ein recht guter Kompromiss. Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist lediglich bei der Aufbereitung der Infos für ein Routing relevant: Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Eben: Du willst service wegwerfen, und ich bietet dir hier einen Kompromiss, der durchaus sinnvoll ist; weil auch die Gewichtung von service-wegen an den Zustiegspunkten einer Fährroute eine andere ist als bei service=alley oder sowas. Nein, ich will nicht Service wegwerfen, um Himmels Willen, ..., nur es muss was her, das a) entweder Services grundsätzlich ausschließt oder b) explizit einschließt. a) ist Gott sei Dank häufig anzutreffen und wird auch fleißig mittels der access-Tags restriktiert. Nur für b) gibt faktisch keine Vorschrift. Hier fehlt die Umkehrlogik, damit ich weiß, dass hier was Wichtiges zu berücksichtigen ist. Die Alternative ist, für den Router falsch zu taggen (aber wenn ich Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher vs. das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum ausgebaut) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. Mit welchem Programm routest Du denn? Gruß Martin ___ 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] AIO - Routing über Fähren
Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:01 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. Ich will jetzt nicht sagen unlösbar, aber ob sich da schon mal jemand dran versucht hat, wage ich zu bezweifeln. Wie ich schon erwähnte, alleine die Restriktionen mit einzubehiehen hat mich fast an den Rand des Wahnsinns getrieben. ... Aber ich bin ja noch da ;-) Gruß Martin ___ 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] AIO - Routing über Fähren
Am 03.11.2010 20:47, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:43 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Ansatzweise korrekt. Problem: Jetzt müssen die Wege rekonstruiert werden. Die beteiligten OSM-Ids der Wege kennen wir aus der Relation. Allerdings kann es passieren, dass der Segmentierungsprozess diese Wege zerhackstückt hat. Die OSM-Id ist also in einer Routing-Topologie niemals eindeutig! Gruß, Carsten Gruß Martin ___ 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] AIO - Routing über Fähren
Am 03.11.2010 20:59, schrieb Carsten Moeller: Am 03.11.2010 20:47, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:43 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Ansatzweise korrekt. Problem: Jetzt müssen die Wege rekonstruiert werden. Die beteiligten OSM-Ids der Wege kennen wir aus der Relation. Allerdings kann es passieren, dass der Segmentierungsprozess diese Wege zerhackstückt hat. Die OSM-Id ist also in einer Routing-Topologie niemals eindeutig! Zusatz: Zugegeben, auch das ließe sich noch in den Griff bekommen. Aber es wird doch hier ersichtlich, dass ein einfaches Tag ala service=wichtig die komplette Kuh mit einer einfachen, pragmatischen Aussage vom Eis kriegt. Gruß, Carsten Gruß Martin ___ 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] AIO - Routing über Fähren
Am 02.11.2010 01:23, schrieb Garry: Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Kann man so nicht wirklich vergleichen! Einen See ist ein Stück der Erdoberfläche die mit Wasser bedeckt ist (abgesehen von den unterirdischen Seen). Eine Badewanne ist ein nach oben offenere Behälter der mit Wasser gefüllt ist. Beide haben im Prinzip nur gemeinsam dass sie mit Wasser gefüllt sind um ihren Zweck zu erfüllen. Ein Flugplatz bzw. Start/Landeplatz ist dagegen ein Stück Land das ausnahmslos dafür definiert ist dass dort regelmässig Boden-Luftübergänge von Fluggeräten stattfinden und von dort eine entsprechende damit verbundene Gefährdung ausgeht die insbesondere alle Luftfahrzeuge (ob Modellflieger oder A380)betrifft. Als Reisender Interessiert mich natürlich nur der Flughafen an dem mein Flug abgeht. Die wenigsten suchen sich ausserdem erst einen Flugplatz - schon gar nicht per Navi - und versuchen von dort aus einen Flug zu ihrem Ziel zu bekommen. Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Aus der Angabe Flugplatz bzw. Start/Landeplatz kann man nun mal nicht mehr erkennen als das dort eine Luft-Boden Übergang von Fluggeräten stattfindet. Und mehr hineinzuinterpretieren wäre schlichtweg falsch! Eine Angabe des immer(?) dreistelligen Flughafenkürzels das auf jedem Verkehrs-Flugticket zu finden sein sollte hat man eine eindeutige Zuordnung zu welchem Flughafen man muss. wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Vielleicht sollte man hier Unterscheiden zwischen Punkt-zu-Punkt-Verbindungen in denen die Eisenbahn eine Strasse ersetzt bzw. wintersichere, kurze Verbindungen ermöglicht (Bsp. Sylt, Lötschbergtunnel, Furkatunnel, Vereinatunnel) und den Autoreisezugverbindungen bei denen man einfach nur die eigene Lenkzeit im Fernverkehr verkürzen möchte (Bsp. Lörrach - Hamburg.). Ersteres sollte so ausgelegt sein dass es schon mit einfachen Routern funktioniert die nicht tausende von unterschiedlichen Details auswerten, - in der Regel fährt man dort einfach hin und kann nach rel. kurzer Wartezeit einfach auf den Zug fahren. Hier macht es Sinn dass in das ganz normale Strassenrouting zu integrieren. Zweiteres erfordert mehr Aufwand und wird in der Regel auch deutlich vorher gebucht. Hier macht es ehr keinen Sinn das ins normale Strassenrouting zu integrieren, man gibt als Ziel den Verladebahnhof ein und routet dann vom Entladebahnhof erneut. Für einen Reiseplaner kann man hier mehr Aufwand investieren und diese Alternative vorschlagen. Entsprechendes gilt natürlich auch für Fähren. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Garry, du drehst Dich im Kreis und ich mich leider auch. Kann Dir aber folgen und schliesse mich Deiner Meinung an. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Bei all den Diskussionen sollte auch der Nutzen von OSM berücksichtigt werden. eben Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Das einzige Problem ist und bleibt natürlich die nun ausführlich geführte Ist das jetzt ein Service oder nicht-Diskussion. schön wärs, Probleme gibt's natürlich noch viele. Hier treffen tatsächlich zwei unterschiedliche OSM-Sichtweisen aufeinander. a) Nutzen, b) Straßenbewertung (WYSIWYG). Nutzen ist kein absolutes Kriterium, solange die Daten die benötigte Information enthalten wird man immer einen Nutzen daraus ziehen können. Straßenbewertung ist ebenfalls ziemlich allgemein gehalten und kann alles bedeuten. WYSIWYG ist eher ein Editorfeature als eine Datenbankregel, vermutlich meinst Du damit das zu taggen, was man vor Ort sieht. Das passt auf physische Eigenschaften wie Oberfläche, Breite etc., aber eben nicht auf die highway-Klassifikation. So z.B. scheinen level_crossings den Taggern nicht wirklich wichtig, weil sieht man ja, dass da Straße und Schiene kreuzen... Nur ein Routing-Topologie-Erzeuger sieht das eben nicht!!! doch klar, sieht er an dem gemeinsamen Node. Das level_crossing dient nur dazu, auszudrücken, dass man es wirklich so meint. Eine Schiene, auf der ein Autozug verkehrt, die wiederum eine Straße kreuzt ... ziemlich heftig, dies ohne level_crossing auseinanderzuhalten! ob da ein Autozug verkehrt oder nicht spielt überhaupt keine Rolle, solange man da nicht von der Straße auf den Zug abbiegen kann. Ja natürlich sind hier Schiene und Strasse mit dem selben Knoten verbunden, weil (WYSIWYG) ist ja so. ... (Aber ist eben Mist). wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich kann mich da nur wiederholen. Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! Ich selbst hab's auch versucht, einen Algo geschrieben, der in noch einigermaßen vertretbarer Zeit die Daten von OSM routingfähig rechnet und das Ganze mal durchgespielt. Mein Fazit ist dabei relativ eindeutig ausgefallen und spiegelt sich in meinen Kommentaren in diesem Thread wider. Wenn es hier also jemanden gibt, der es geschafft hat, seine OSM-Daten routingfähig zu kriegen und dabei sämtliche OSM-Relationen berücksicht, der möge sich bitte melden. SuperComputer-Benutzer sind von dieser Umfrage allerdings ausgeschlossen ;-) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 01.11.2010 21:18, schrieb Carsten Moeller: Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kleiner Zusatz noch: Oder auch schon gesehen: railway=rail + highway=residential + motorcar=yes als ein Weg! War eigentlich auch richtig, weil Brücke (was fehlte), aber letztere interessiert einen Router eigentlich nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 01.11.2010 21:08, schrieb Stephan Knauss: On 01.11.2010 20:09, M∡rtin Koppenhoefer wrote: m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug Das hatten wir schon mal, ist etwas über ein Jahr her. Wege komplett ohne Nodes habe ich damals als Ergebnis der Diskussion gelöscht: http://www.openstreetmap.org/browse/changeset/2250280 Die hatten damals auch schon länger keine Nodes mehr. Wege mit nur einem Node hatten wir IMHO auch angesprochen, dann aber stehen gelassen weil es dafür eventuell Gründe geben könnte. Mir persönlich wäre auch lieber wenn ein way aus 2 oder mehr Nodes bestehen muss. Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: 48238597 23907650 83584123 83584739 82651049 83602048 83602054 83633771 Da könntest du dir fast schon jeden von Hand ansehen und bei Bedarf aufräumen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Tschuldigung kurz zwischengegrätscht zu haben Bei dieser Analyse sollte man evtl auch aufanderfolgend gleiche Knotenreferenzen und ggf. unterschiedliche Referenzen mit gleichen Koordinaten mit einbeziehen und ggf. wenn unsinnig reduzieren. Dann werden's schon ein paar mehr Ein-Knoter. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 30.10.2010 23:35, schrieb Garry: Am 29.10.2010 20:47, schrieb Carsten Moeller: Natürlich ist railway=rail + motorcar=yes Mist. Hab das aber jetzt so häufig gesehen, dass ich mich schon drauf eingestellt habe und dies entsprechend berücksichtige. Mist ist vor allem wenn man tausende von Sonderfällen in einem Programm explizit berücksichtigen muss und nicht auf wenige Grundregeln vereinfachen kann. Verfeinern kann man dann immer noch.. Gerald ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Gerald, ja, das ist eigentlich kaum noch beherrschbar. Ich finde das ja schön, dass man OSM-seitig die Welt korrekt beschreiben will und auch tut. Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. Bei all den Diskussionen sollte auch der Nutzen von OSM berücksichtigt werden. Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. Alle Briefkästen in Norddeutschland anzuzeigen ist eine Sache, ein ganz anderes Kaliber ist halt das Routing. Hier ist OSM noch extrem schwach auf der Brust. Nachträglich da irgendwelche Routing-Zusatz-Tags einzuführen halte ich für nicht durchsetzbar. Dafür müsste man im Nachgang zu viel ergänzen. Die bestehenden Tags reichen eigentlich aus. Das einzige Problem ist und bleibt natürlich die nun ausführlich geführte Ist das jetzt ein Service oder nicht-Diskussion. Hier treffen tatsächlich zwei unterschiedliche OSM-Sichtweisen aufeinander. a) Nutzen, b) Straßenbewertung (WYSIWYG). So z.B. scheinen level_crossings den Taggern nicht wirklich wichtig, weil sieht man ja, dass da Straße und Schiene kreuzen... Nur ein Routing-Topologie-Erzeuger sieht das eben nicht!!! Eine Schiene, auf der ein Autozug verkehrt, die wiederum eine Straße kreuzt ... ziemlich heftig, dies ohne level_crossing auseinanderzuhalten! Ja natürlich sind hier Schiene und Strasse mit dem selben Knoten verbunden, weil (WYSIWYG) ist ja so. ... (Aber ist eben Mist). Die Diskussion habe ich aber auch schon elend lange geführt und am Ende war halt die WYSIWYG-Meinung vorherrschend. Ich muss also damit leben und das Beste draus machen. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 30.10.2010 11:02, schrieb Stephan Wolff: Am 29.10.2010 10:56, schrieb Ulf Lamping: Wenn man daher den Zufahrtsweg zusammen mit der Fähre als Verbindung von A nach B ansieht - und darum geht es hier ja - paßt service auf einmal viel weniger. Dann ist es nämlich keine schnöde Zufahrt mehr, sondern Teil einer Verbindung - und da paßt ein unclassified dann schon wieder viel eher. Bei vielen Fähren steht an der Zufahrt zunächst das Schild Z250 mit dem Zusatz Fährbenutzer frei, danach führt der Weg auf eine große, parkplatzähnliche Fläche, dann durch ein Tor im Antiterrorzaun zu einer Kontrollstelle mit Schlagbaum und schließlich über eine Hafenfläche ohne baulich abgegrenzte Fahrbahn zum Schiff. Ein durchgängiger highway=servive ist schon fast eine übertriebene Hilfestellung für den Router. :-) Nur leider wird ohne Hilfestellung auch in der Zukunft kein vernünftiges Routing über OSM-Daten möglich sein!!! OSM-Routing ist mittlerweile eine Wissenschaft für sich. Wenn ein Router solch eine Fähre einplanen soll, muss das Programm, das die OSM-Daten aufbereitet, die Zufahrtswege entsprechend umsetzen. Fußgänger über Busse, Bahnen und Personenfähren zu routen, erscheint mir weitaus schwieriger. Nein. Routing über Busse und Bahnen ist mit wenigen Ausnahmen ähnlich. Es kommt einzig und alleine auf die Verbindung der Wege an. Also auf gemeinsame Knotenpunkte. Ist die Bushalte irgenwo 3 Meter neben der Strasse wird's schon fast unmöglich, es sei denn während des Segmentierungsprozesses werden gleichzeitig geographische Heuristiken herangezogen. Das ist aber in einer vernünftigen Rechenzeit kaum noch verarbeitbar. Ein SnapToGrid ist hier auch keine Hilfestellung, da das zu viele Verbindungsfehler produziert. Und ein Schau mal was kommt nach dem unwichtigen Weg - Kommt da eine wichtige Fähre-Prinzip kann eigentlich nur noch ein Supercomputer in vernünftiger Zeit verarbeiten. Es geht hier schliesslich nicht um 1000 Knoten, sondern alleine für Europa mittlerweile um 10 (Zehn!) Millionen, und das sind nur die Hauptstraßen! Gruß, Carsten Viele Grüße, Stephan PS: wasserseitig gibt es meist keine Absperrungen vor den Fährschiffen. Terroristen werden aufgefordert, nur von der Landseite anzureisen. ___ 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] AIO - Routing über Fähren
Am 28.10.2010 22:55, schrieb Chris66: Am 28.10.2010 21:36, schrieb Carsten Moeller: Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Ein chaotisches Beispiel ist da der Hindenburdamm nach Sylt. Mal kommt man rüber dann wieder nicht, weil irgendwer per GPS alles verschlimmbessert hat. Der ist als route=shuttle_train eingetragen Und dann sind da noch die level_crossings. Ja, wer die vergisst, der wird fast jeden Router von der Straße auf die Schiene kriegen. Egal wo ;-( Deshalb hatte ich die Route NUR an den Endpunkten mit dem Straßennetz verbunden. Stimme übgrigens damit überein, die Anschlüsse zu Fähren und Autozügen NICHT als service zu taggen. Dies würde bedeuten, dass jede Routing-Topologie sämtliche services berücksichtigen müsste. ??? Aus meiner Sicht ist highway=service korrekt. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich stimme mit Dir in allen Punkten überein. a) es ist ein Service b) route=shuttle_train ist exakt! Nur leider habe ich route=shuttle_train nur ganz selten in den XMLs gesehen. Die Tendenz war doch eher railway=rail und motorcar=yes. Ferner ist es für Konvertierer ganz schwer vorherzusagen, ob ein Service nun eine hohe Prioriät geniesst oder nur zur nächsten Milchkanne führt. Folglich muss eine Router solche Wege immer mit durchforsten. Es sei denn man könnte noch ein weiteres Hinweis-Tag an dieser Stelle setzen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 09:30, schrieb Chris66: Am 29.10.2010 08:56, schrieb Garry: Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er Und wenn der Service genau in der Mitte der Strecke liegt? Das wäre der Worst-Case! Ich meine in allen Fällen in denen service nicht Anfang und/oder Ende der Strecke ist. Unter Umständen ist das Service-Stück ja auch noch entgegengesetzt zur Zielrichtung. Mir ist bekannt dass Garmin ein Problem mit niederklassifizierten Straßen in der Mitte der Route hat, aber ich dachte die modernen A-Star etc. Algos kämen damit klar. Eine bessere Lösung als deswegen die Zufahrtswege als primary zu taggen wäre eine Annotationstag wie mkgmap:routing_class=+3 oder so... Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ja, diese Art Tags wären SUUUPER! Nur leider sehe da jetzt kaum noch eine Chance, das nachträglich irgenwie in die Daten hineinzuoperieren. Einfacher wäre es doch, eine Mischaussage ala highway=wichtige_zufahrt oder so einzuführen. mkmap:routing_class=+3 halte ich für wenig durchsetzungsfähig - weil irgenwie kryptisch bzw. spezifisch klingend. Aber irgendwas muss man da mal in Angriff nehmen. Hier fehlt in OSM eindeutig eine wichtige Info für einen doch durchaus wichtigen Anwendungsfall, nämlich das Routing. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 10:24, schrieb Sven Geggus: Chris66chris66...@gmx.de wrote: ??? Aus meiner Sicht ist highway=service korrekt. Eben, wüsste nicht was besser passt, classified ja wohl kaum. Warum ein Router service _nicht_ berücksichtigen sollte müsste Carsten erst mal erklären. Für größere Parkplätze möchte man das beispielsweise ohnehin haben. Meine Rheinfähre hat jedenfalls Servicewege: http://osm.org/go/0DP7TJddE-- Gruss Sven Hallo Chris, natürlich ist highway=service korrekt. Aber eben nicht ausreichend. Siehe meinen Kommentar oben. Ich will nur kurz ein paar Daten liefern: Um ein vernünftiges Routing über Europa aufzubauen, braucht man in etwa 650MByte an segmentierten OSM-Wegen. Das sind dann faktisch nur die Start- und End-Punkte und ein paar zusätzliche Infos wie Kosten etc. Das ist noch einigermaßen schlank, wären aber nur die Highways. Würde man jetzt noch alle Services und, welche ich für wichtiger erachte: Tracks und Pedestrians, mit aufnehmen, wäre das schon eine beträchtliche Menge an Daten (ca. 1 Gig) - ok - immer noch verarbeitbar - jedoch jetzt mit services angefüttert, die zu 95% uninteressant sind. Ferner müsste ein Router diese jedes Mal mit abklappern. Zur Zeit ergeben sich aus den osm-Daten für Europa ca. 10 Mio. Vertices (WorstCase-Routing). Diese schafft mein Rechner (olle Kiste) in ca. 30 Sekunden. Entsprechend würde sich ein Routing stark verlangsamen, wenn auch noch unwichtige Verbindungen hinzukämen. Des Pudels Kern eines Aufbaus einer solchen Topologie und eines späteren Routings liegt aber in bestimmten Voraussagen. Ein AStar ist davon genau so betroffen wie ein doofer Dijkstra. Der Algo ist also nicht der geeignete Schlüssel OSM-Daten diesbezüglich einigermaßen nutzen zu können. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 11:35, schrieb M∡rtin Koppenhoefer: Am 28. Oktober 2010 21:36 schrieb Carsten Moellercmindivid...@gmx.de: Am 26.08.2010 13:44, schrieb M∡rtin Koppenhoefer: Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Du meinst damit aber nicht, motorcar=yes an die Schienen zu taggen, oder? Das hielte ich für extrem falsch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Martin, Deiner Kommentarstrecke nach zu urteilen, verstehst du was von Routing. Das ist schön. - Nein, das ist jetzt ernst gemeint. :-) Natürlich ist railway=rail + motorcar=yes Mist. Hab das aber jetzt so häufig gesehen, dass ich mich schon drauf eingestellt habe und dies entsprechend berücksichtige. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads jetzt als Binaerformat
Am 22.09.2010 23:48, schrieb Frederik Ramm: Hallo, Robert S. wrote: Und was ist zu machen, wenn man z.B. mit Maperitive[1] eine Karte rendern will, der braucht ja .osm-XML-Dateien. Bisher reichte es ja, die .bz2-Datei mit 7.Zip oder WinRar zu entpacken. Und nun...? osmosis --read-bin file.osm.bpf --write-xml file.osm Oder warten, bis Maperitive das .osm.bpf selber auch unterstuetzt. Es wird bald eine einfache C-Implementierung fuer die Umsetzung pbf-osm geben, die kann dann jeder (z.B. der Maperitive-Entwickler) einfach in sein Programm einbauen. Aber die alten .bz2s gibt es ja noch, und die verschwinden auch nicht morgen. Fruehestens uebermorgen ;) Bye Frederik Na ja, wenn man da mal - wenn auch etwas verspätet zwischengrätschen darf... Ich halte bpf für eine Alternative, nicht jedoch für eine wirklich gute Lösung. Die Annahme, dass alles da draußen auf osmosis aufsetzen wolle oder mal eben ganze Importstrukturen umkippen wird, um sich dem doch eher gruseligen Binärgefriggel-Format anzuschließen, halte ich für gewagt. Eine 30%ige Reduzierung der Transportmengen wäre durchaus auch anders zu erreichen. Nicht jeder benötigt immer alles. Als gutes Beispiel sehe ich hier die Cloudmade-Philosophie Extrakte für verschiedene Anwendungsfälle bereitzustellen. Da ist ein europa-highways.osm plötzlich nur noch ein Drittel so groß wie das Original. Analog wäre z.B. auch denkbar, die ganzen Meta-Infos wie Autor, TimeStamp, etc. aus den Tags rauszulassen und nur reine Nutzdaten zu komprimieren. Wette, das geht dann auch auf 30% runter! Aber der wichtigste Aspekt zum Schluss: Ich weiß nicht wie viele XMLs ich bereits analysiert habe und so ganz schnell auf kleine aber nicht unwichtige Dinge und Fehlerchen aufmerksam geworden bin. Diese Option wird es dann ja in Zukunft nicht mehr geben. Schade. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 26.08.2010 13:44, schrieb M∡rtin Koppenhoefer: Am 26. August 2010 10:50 schrieb 007northc...@gmx.de: Indem man die Fährverbindung (route=ferry) inkl. access-rights (motorcar=yes/no) richtig in OSM einträgt. Ein beliebter Fehler ist, die Route nicht mit dem Straßennetz zu verbinden. Oh ja, das war hier bei einer der Rheinfähren ein Problem. Da war der Serviceweg zur Fähre nicht mit der Fährspur verbunden. Ist an der Stelle denn highway=service das richtige oder eher highway=unclassified ? je nachdem kann das m.E. evtl. bis secondary gehen, je nach Verkehrsbedeutung. Normalerweise würde ich sagen tertiary. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Ein chaotisches Beispiel ist da der Hindenburdamm nach Sylt. Mal kommt man rüber dann wieder nicht, weil irgendwer per GPS alles verschlimmbessert hat. Und dann sind da noch die level_crossings. Ja, wer die vergisst, der wird fast jeden Router von der Straße auf die Schiene kriegen. Egal wo ;-( Stimme übgrigens damit überein, die Anschlüsse zu Fähren und Autozügen NICHT als service zu taggen. Dies würde bedeuten, dass jede Routing-Topologie sämtliche services berücksichtigen müsste. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 01:20, schrieb Garry: Am 28.10.2010 22:55, schrieb Chris66: Stimme übgrigens damit überein, die Anschlüsse zu Fähren und Autozügen NICHT als service zu taggen. Dies würde bedeuten, dass jede Routing-Topologie sämtliche services berücksichtigen müsste. ??? Aus meiner Sicht ist highway=service korrekt. Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er ja prüfen ob die Verwendung eines highway=service sinnvoll ist, aber bei langen Strecken jeden service abzuklappern ob er nicht doch an eine geeigneten Transportlösung anbindet dürfte aufwendig werden... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Und wenn der Service genau in der Mitte der Strecke liegt? Das wäre der Worst-Case! Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] New Routing Solution for OSM
Ups! This is the address http://osm2po.de ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Felix Hartmann schrieb: I think the main part that has to be done here is that ferries, or motorails however as well aerialways get connected to the main road network using lines (routing over polygons is so complicated that no router will soon master it in a useful way). How they are connected should be dependant on the transport mode to use. Image huge ferries with different, but consistent places to enter. We could have highway=footway pier=yes (or similar)for pedestrians entering the ferry (this is actually one of the rare cases I like to see footway and not path), highway=service motorcycle=yes foot=no bicycle=yes highway=service access=no motorcar=yes hgv=yes And the ferry route should connect all three. Another example would be a cable_car. We should have highway=footway (or another key) to connect the street network to the cable_car. If there are steps inside the building, well then lets add a section highway=steps.. The principle should be no matter what kind of line there is that can be used somehow, it should be interconnected with all other transport usable lines. This means that we should also connect railways to roads, because otherwise no autorouter can calculate routes using busses and trains (with walking from one to another) for example. Only airports I would rather just connect by having a relation list to which other airports you can get from airport XY. I get to the conclusion that we exactly have two perspectives. First there is the question of how to get from A to B including public means of transport. The other one guides me to the closest parking lot. A cable car for instance has the same quality as an aerialway. But not as highway=footway. The latter is rather like a highway=service. You can use a car. Ok. it might be forbidden but you can. Offering mountain tops and similar things as addresses on your routing topology will blow up the data dramatically. The key to a fast routing is the reduction of data. Make things as simple as possible, but not simpler (Einstein). There are some grey zones. I am living in a highway=pedestrian connected to a highway=service, so I decided to take these tags into account but gave them a low priority so the router selects them only if there is no other way. I do agree. Railways, aerialway etc. should be connected to highways. But this should not be expressed by connecting same nodes. Here ramps or links come into play. If you have a closer look at todays OSM-Data railways are in fact connected to streets. But I wonder if you'd like to stop a train by parking your car on a railroad crossing ;-) What about aerialways? Are they connected, too? In the air? A highway=steps would imply you can use your car here. I think we should strictly distinguish between highway and other tags. If I understood the intention correctly then highway is something you can drive on. Even on highway=pedestrian but not on steps. I hope OSM will take these two perspectives into accoung one day. So we can have routable highway tags like highway=railway, highway=ferry, etc. These are much easier to handle (and to tag) than railway=rail + motorcar=yes + amenity= ... and so on. On the other hand we should consider the real world. This of course means we'll need to build topologies on relations or tags like motorcar=yes, railway=rail. Regards Carsten (alias PiMapper) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: Am 15.01.2010 23:02, schrieb Carsten Moeller: yes, osm relations are one possible solution. But from the view of a pgRouter it is a very stony way to collect that data back into a routing table. You are right, that there should be a tag like terminal or ramp or even simpler link. Seems there's at least no difference in principle that this would be useful :-) We already have the established amenity=ferry_terminal and an amenity=motorail_terminal wouldn't be very different in functionality - no need to develop a complete new name IMHO. As you certainly want to have a different rendering for these two, it might not be a good idea to have just a single tag like amenity=terminal for this. From the perspective of a street map a pickapack railway or ferry has the same quality as e.g. highway=pedestrian. Sorry, i don't get your point here. On highway=pedestrian I'm not allowed to drive (except maybe for un-/loading at specific times) - which is completely different IMHO. So I'd prefer sth. like highway=railway, highway=ferry, highway=railway_link and highway=ferry_link. This info is enough for pgRouting to create a topology. Additional properties can be assigned to amenity or railway of course. For a ferry (if all is tagged well), this can already be achieved. You'll travel: highway=service amenity=ferry_terminal (if it allows cargo=vehicle) ferry route (as tagged and displayed already on the maps) amenity=ferry_terminal (again with cargo=vehicle) highway=service The same principle applies for a railway as well: highway=service amenity=motorail_terminal motorail route (see below) amenity=motorail_terminal highway=service The exception for the railway - compared with ferries - is, that the railway grid will physically connect a lot of places. There's certainly a physical railway connection from the sylt shuttle mainland station to italy. But the railway company just won't offer you that service :-) Now you can invent a special tag (as you intended) for the short distance or point to point connections, like sylt shuttle, channel tunnel and alike applies for several short distance tunnel services in the alps. Then you'll need *another* mechanism for the long distance travel from hamburg to vienna (Deutsche Bahn is offering about roughly 20 such dedicated routes - not more) with just exactly the same problem: Travel with your car pickapack on a train from A to B. That's why I was thinking about relations. However, as you may want to display on a map only short distance but not long distance pickapack, it even makes sense IMO to have two different ways to tag this. One to tag point to point connections as you'd suggested and one for long distance connection grid connections using relations. May I suggest to just keep existing stuff for ferries and use amenity=motorail_terminal and highway=motorail (which seems to be the right translation for german Autoverladung/Autoreisezug) for the short distance ways? Regards, ULFL P.S: Next time, using the tagging mailing list seems more natural for these or similar discussions ;-) Yes, I do agree. We should have tags describing short and long distances. The latter is possibly best expressed by using relations. Yes, there are already tags for our problem: highway=service amenity=ferry_terminal (if it allows cargo=vehicle) ferry route (as tagged and displayed already on the maps) amenity=ferry_terminal (again with cargo=vehicle) highway=service But this kind of tagging is hardly parsable. In case of routing, I don't want to collect all highway=service in the topo. For route=ferry or rail=railway I can distinguish if they are subtagged by motorcar=true or not. As a consequence the highway=service then should be subtagged with sth. like ferry-link. But this guides me to my first approach again. In my opinion, it should be as simple as possible. I'm afraid, only few people will follow this tagging pattern and we'll end up in a forest. Once again, the main problem is the parsing itself. In case of the upper example you will have to analyze relations in a second step. If you tagged them directly It's just a one shot parsing. Another problem, as I've already mentioned before, are the connections (even same nodes) between railroads and streets. This is a annoying and kills the ability for OSM to route satisfyingly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: Am 16.01.2010 10:16, schrieb Carsten Moeller: Yes, I do agree. We should have tags describing short and long distances. The latter is possibly best expressed by using relations. Yes, there are already tags for our problem: highway=service amenity=ferry_terminal (if it allows cargo=vehicle) ferry route (as tagged and displayed already on the maps) amenity=ferry_terminal (again with cargo=vehicle) highway=service But this kind of tagging is hardly parsable. In case of routing, I don't want to collect all highway=service in the topo. Sorry to say, if you don't take highway=service ways into account, your whole routing program gets very certainly a lot less useful to a lot of end users anyway. For route=ferry or rail=railway I can distinguish if they are subtagged by motorcar=true or not. As a consequence the highway=service then should be subtagged with sth. like ferry-link. But this guides me to my first approach again. In my opinion, it should be as simple as possible. That's true. But it should be as simple as possible for the mappers (as long as it's somehow usable for routers) :-) If you say the mappers have to improve tagging, otherwise I won't be able to write a router I'd say write a better router. It's not because I don't like you, it's because I know that half of the mappers won't do it anyway and you'll just end up with a router not working in a lot of situations. I'm afraid, only few people will follow this tagging pattern and we'll end up in a forest. That's no news, regardless of what we'll discuss here ;-) Once again, the main problem is the parsing itself. In case of the upper example you will have to analyze relations in a second step. If you tagged them directly It's just a one shot parsing. If you don't want to analyze relations, you will also miss other required stuff (e.g. turn restrictions). A router not analyzing relations has no future IMHO. Another problem, as I've already mentioned before, are the connections (even same nodes) between railroads and streets. This is a annoying and kills the ability for OSM to route satisfyingly. No, it doesn't ;-) Regards, ULFL Oh dear, don't remind me of the turning restrictions ~~~ This is another non fitting pair of shoes ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] TAG-Suggestion: highway:trailer_shipment
Hey folks, first of all I'll have to apologize my bad english. I also hope that this is the right place for my question. I'm playing around with pgRouting and OSM - mainly in the north of Germany. (Schleswig-Holstein / Hamburg) I came across some annoying issues. There are several islands that can only be reached by ferry or train. So I filtered tags like railway=rail, route=ferry in combination with motorway=yes (For the germans: you all should know the Hindenburdamm to the island Sylt). The first thing that is quite wrong is that streets are connected to railroads the whole way long. In case of Sylt you exactly have one ramp in Niebuell and another in Westerland (Sylt). In between you have to go pickapack. By the way, it's the same problem with the ferries. So, as these kinds of transports' main purpose is replacing highways, they should be regardes AS highways. So what about tags like highway = trailer_railway highway = trailer_ferry we then could connect them to streets as if they were highways. Regards PiMapper ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: Am 15.01.2010 15:43, schrieb Carsten Moeller: Hey folks, first of all I'll have to apologize my bad english. I also hope that this is the right place for my question. I'm playing around with pgRouting and OSM - mainly in the north of Germany. (Schleswig-Holstein / Hamburg) I came across some annoying issues. There are several islands that can only be reached by ferry or train. So I filtered tags like railway=rail, route=ferry in combination with motorway=yes (For the germans: you all should know the Hindenburdamm to the island Sylt). The first thing that is quite wrong is that streets are connected to railroads the whole way long. In case of Sylt you exactly have one ramp in Niebuell and another in Westerland (Sylt). In between you have to go pickapack. By the way, it's the same problem with the ferries. So, as these kinds of transports' main purpose is replacing highways, they should be regardes AS highways. So what about tags like highway = trailer_railway highway = trailer_ferry we then could connect them to streets as if they were highways. Just yesterday I've collected infos about a more general approach to this. However, I've focussed on the terminals and not on the way between them. The problem: This stuff is also available for long distance (e.g. overnight) travel from north to south europe with varying routes, so simply using highway=trailer_railway probably won't work well here. Maybe better using a relation for this? I've appended my first ideas for a proposal page. Regards, ULFL motorail Regular transportation of car/motorcycle packed on a train and travels to the destination. The driver travels together with it's vehicle and may need to stay inside the vehicle or travels in a normal (or sleeping) train waggon. Both short term (e.g. through the channel tunnel) and long term (e.g. overnight from Hamburg to Vienna) travels are common. This is *not* for plain car transportation, e.g. delivering a newly build car from the manufacturer to it's a customer. What to tag: The specific place to board the train. Suggested tag: amenity=motorail_terminal (on node or area) name=* (e.g. Autozug Terminal München-Ost) operator=* (e.g. Deutsch Bahn AG) Clarify: Also tag route/destinations? Maybe using relations? See Also amenity=ferry_terminal Weblinks http://en.wikipedia.org/wiki/Motorail http://de.wikipedia.org/wiki/Autoverladung (german) Hello Ulf ... yes, osm relations are one possible solution. But from the view of a pgRouter it is a very stony way to collect that data back into a routing table. You are right, that there should be a tag like terminal or ramp or even simpler link. From the perspective of a street map a pickapack railway or ferry has the same quality as e.g. highway=pedestrian. So I'd prefer sth. like highway=railway, highway=ferry, highway=railway_link and highway=ferry_link. This info is enough for pgRouting to create a topology. Additional properties can be assigned to amenity or railway of course. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
