Re: [OSM-talk] Proliferation of path vs. footway
Nop wrote: Hatto von Hatzfeld schrieb: Official is new and has only one meaning. From Map features: official is used for ways dedicated to a certain mode of travel by law. Usually indicated by a traffic sign. I really do not see where the use of designated has differed from this definition. Which of the 5 definitions of designated do you mean? :-) *You* talked about 5 different meanings documented in the wiki. I found that all of them say something like specially designated (typically by a government) for use by a particular mode (or modes) of transport. You missed my central point when you skipped this phrase in your answer. Just read this topic from the beginning and you should understand. I have read most of this discussion - but instead of reading it twice I prefer to go out for mapping some cycleways ... By the way: Just read http://lists.openstreetmap.org/pipermail/talk-de/2008-December/031057.html (and the following discussion) and you should understand what I mean. Bye, Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Roy Wallace wrote: On Thu, Aug 13, 2009 at 9:49 PM, Richard Mannrichard.mann.westoxf...@googlemail.com wrote: The deprecation of footway/cycleway was voted on (by not many people, but nevertheless), and the deprecation was rejected, but some people don't seem to be able to take no for an answer. It was? Maybe that was before my time. On http://wiki.openstreetmap.org/wiki/Approved_features/Path you may count how many people approved the proposal but explicitly opposed the deprecation of existing tags. Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Martin Koppenhoefer wrote: 2009/8/13 Nop ekkeh...@gmx.de: Proposal #2: Introduce offical dedication Leave old tags as they are and accept that foot/cycleway and designated are as fuzzy as described above. Clarify that these tags only give information on possible use, but not about the legal situation. Introduce a new tag biclyce/foot=official to tag the strict use case of road-signed ways or corresponding legal dedication. This way, nothing needs to be changed in existing fuzzy tagging, but real foot/cycleways are simply tagged by adding an official or changing designated to official if appropriate. IMHO if this solution is chosen we should also deprecate designated, as it is of no more use, and would just lead to possible problems when contradictory to official. I appreciate Nop's proposal - but why replace designated by official? I do not see that designated has been used in the past with a meaning differing from what official would be used for in future. Or did I miss anything in this discussion? Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Nop wrote: Hatto von Hatzfeld schrieb: I appreciate Nop's proposal - but why replace designated by official? I do not see that designated has been used in the past with a meaning differing from what official would be used for in future. Designated is linked to footway/cycleway and there are about 5 different interpretations on what it means, all of them documented somewhere in the Wiki. You are exaggerating. They all say something like specially designated (typically by a government) for use by a particular mode (or modes) of transport. Official is new and has only one meaning. From Map features: official is used for ways dedicated to a certain mode of travel by law. Usually indicated by a traffic sign. I really do not see where the use of designated has differed from this definition. Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=cyclefootway
Russ Nelson wrote: On Mar 28, 2009, at 1:50 AM, Stephen Hope wrote: I don't feel right calling it a cycleway if they have to give way to other users. Cyclists ALWAYS have to give way to other users. It's a simple matter of the laws of physics. At least here in Germany there are cycleways which are not allowed for pedestrians and others which are shared by cyclists and pedestrians. But maybe there are dedicated cycleways in some places where pedestrians enter at the risk of their lives? In some places (e.g. in Munich) it is the life of the cyclist which is risked by pedestrians entering the cyclelists' exclusive track ... Bye, Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] power=line
According to the map features the tag power=line may be completed by a tag wires=single|double|triple|quad. I have some doubts about the meaning of wires in this case. Map features say about the wires tag: Number of wires per power cable. single (1), double (2), triple (3) or quad (4). The number of cables may be specified using power=cables. Obviously power=cables is a mistake; it should probably be cables=[number]. Please could some native speakers tell me whether this interpretation is correct: A power line is a set of cables hanging between power towers; each cable may consist of one or more wires. Thus a German 110 kV line named 0802 with 6 cables [plus one neutral conductor?], each consisting of a single wire, may be tagged as: power=line cables=6 wires=single ref=0802 Because of the scarce documentation of power=cables some people started to tag e.g. wires=6*single. I think this should be changed to cable=6, wires=single. Am I right? Hatto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Einschränkungen Taggen
Matthias Versen wrote: Ich habe das jetzt mal so getaggt : access=agroculture Laut http://wiki.openstreetmap.org/wiki/Key:access sollte das so heißen: access=agricultural Anmerkung für die Allgemeinheit: http://wiki.openstreetmap.org/wiki/DE:Key:access kennt daneben allerdings auch agricultural=*, wobei mir nicht klar ist, was (außer yes und no) für das * gesetzt werden könnte. Jemand :-) könnte mal dafür sorgen, dass die deutsche und die englische Seite miteinander übereinstimmen. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender ohne Straßen?
Martin Koppenhoefer wrote: Am 20. März 2009 22:11 schrieb Hatto von Hatzfeld ha...@salesianer.de: Mir fehlen eben auf, dass Osmarender derzeit - nun ja - *sehr* viel auslässt beim Rendern (z.B. Straße, Flüsse, Fuß- und Radwege). Siehe hier: http://www.openstreetmap.org/?lat=50.9792lon=6.9796zoom=13layers=0B00FTF Screenshot dazu: http://salesianer.de/s/Osmarender-ohne-Strassen.png Wie kommt ein solcher Unfall? das kommt, wenn man den Fokus zu stark auf die Gebäude richtet. Ohne Gebäude sieht es aber auch nicht besser aus, wenn man da nur ein paar Seen und kleine Wälder sieht (derzeit z.B. im Süden von Aachen). Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Martin Koppenhoefer wrote: Dimitri schrieb: Ist auch nicht so toll, wir haben hier in Aachen die Ringlinie 3 die gibt es in die eine Richtung als 3A und in die andere als 3B. Gestern habe ich diese um 3 Haltestellen verlängert und mußte dann immer überlegen kommt diese Haltestelle jetzt in 3A oder in 3B. Die Wahrscheinlichkeit da Fehler zu machen ist groß. [...] das wäre kein Problem, wenn Du die Haltestellen an die richtige Straßenseite malen würdest. Ein sehr gutes Argument. Warum wohl Dimitri darauf nicht eingegangen ist? Ich möchte zu dieser Diskussion nur mal bemerken, dass mich Martins Argumente überzeugt haben. Dimitri scheint sich da eher in etwas verbissen zu haben. Just my impression ... Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einschränkungen Taggen
Matthias Versen wrote: Hallo ! Wie kann man folgende Wegebeschränkungen Taggen : http://mversen.de/temp/schild.jpg Einzelnd ist das kein Problem, aber wie macht man das in diesem Zusammenhang ? Leider habe ich in den verschiedenen Diskussionen um das Kennzeichnen derartiger Einschränkungen inzwischen den Überblick verloren. Mir scheint das daran zu liegen, dass eine allgemein akzeptierte Wiedergabe der diversen möglichen Und- und Oder-Verknüpfungen von Einschränkungen noch nicht existiert. Bei der Gelegenheit habe ich auch eine Frage: Wir würdet Ihr folgende Schilderkombination in Tags übersetzen? http://wiki.openstreetmap.org/wiki/Image:Nullverkehrszeichen.jpg Habe ich hier in Köln gesehen. Es steht an einer Stelle, an der man von einem Trampelpfad (zu Fuß oder per Mountainbike nutzbar) auf einen Kiesweg kommt. SCNR, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osmarender ohne Straßen?
Mir fehlen eben auf, dass Osmarender derzeit - nun ja - *sehr* viel auslässt beim Rendern (z.B. Straße, Flüsse, Fuß- und Radwege). Siehe hier: http://www.openstreetmap.org/?lat=50.9792lon=6.9796zoom=13layers=0B00FTF Screenshot dazu: http://salesianer.de/s/Osmarender-ohne-Strassen.png Wie kommt ein solcher Unfall? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koordinateneingabe in der OSM-Suche
Johann H. Addicks wrote: In http://www.geoclub.de/viewtopic.php?f=70t=30683 kam heute die Frage auf: Google-Maps versteht Eingaben wie N48° 45.123 E008° 45.123 und zeigt promt das umgerechnete Lat/Lon an. Die OSM-Suche tut das leider nicht. Any ideas? Man sollte das auf www.openstreetmap.org einbauen. :-) Bis dahin: http://www.salesianer.de/util/googlemap2osm.html Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] service=alley
Tobias Wendorff wrote: Hatto von Hatzfeld schrieb: Auf http://wiki.openstreetmap.org/wiki/DE:Map_Features steht zu service=alley: Gasse, d.h. ein meist eher schmaler Weg, der zwischen Häusern oder Grundstücken hinein- oder hindurchführt (kann auch eine Sackgasse sein) und Zugang zu örtlichen Gegebenheiten bietet. Zu verwenden mit highway=service. Das passt hier genau. Also kann man mit einem Pkw da durchfahren? Trotzdem würde ich width dranhängen und vielleicht noch Lkw etc. ausgrenzen. In den Fällen, die ich vor Augen habe, fahren die Anwohner mit dem PKW dort hinein, wenn sie z.B. die Einkäufe ausladen oder die gehbehinderte Oma einladen wollen. Bei einem Umzug wird auch ein kleinerer LKW hineinfahren. Sonst fährt aber jeder außenherum (d.h. über die residential-Straße), einfach weil das bequemer ist. Wenn es sich um eine normale Gasse in einer Altstadt ohne Zugangs- und Zufahrtscharakter handelt, ist service=alley in meinen Augen nicht angebracht. Stimmt; da gibt es sicher Grenzfälle. Die Einbahnstraßen auf http://www.openstreetmap.org/?lat=51.066083lon=6.865704zoom=18 sind z.B. auch nicht breiter, aber doch residential (oder living_street), weil man durch sie durchfahren muss, wenn man zu bestimmten anderen Straßen kommen will. Sogar (kleine) Linienbusse fahren da hindurch. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] service=alley
Tobias Wendorff wrote: highway = service sollte ausschließlich für Vehicle und auch Tiere, die zur Fortbewegung dienen, verwendet werden. Die Addition von service = alley ergibt daher für mich, dass die schmale Gasse breit genug für Autoverkehr ist. Alternativ könnte man auch eine Straße (z.B. highway=residential) nehmen und die Breite dazu angeben. Wenn das aber unter 2,5 - 3 m ist, würde ich davon eher absehen. Ich sehe das ebenso. Um ein konkretes Beispiel zu geben, das keine historische Altstadt-Gasse, sondern neuzeitliche Bauweise zeigt: http://www.openstreetmap.org/?lat=50.996844lon=6.9833zoom=18 Die entsprechende Google-Map-Ansicht ist diese hier: http://maps.google.de/maps?ll=50.996844,6.9833z=18 Da kann man sehr schön sehen, wie sich die Heinrich-Blum-Straße (als residential) von diesen Seitenwegen unterscheidet. Die Straße ist breit genug für Gegenverkehr und auch zum Parken am Straßenrand und hat auch (niedrige) Bürgersteige. Diese Wege dagegen dürfen zwar auch von Autos befahren werden (und das geschieht auch); aber man muss dazu über den Bürgersteig fahren, und Begegnungsverkehr ist nicht oder nur bei sehr schmalen Autos möglich. Ich finde, dass highway=service mit ergänzenden service=alley (und access=yes oder access=destination) hier genau das richtige ist. Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway=yes bei Fahrradwegen und weiteres
Patrick Kolesa wrote: Ich fahre öfters auf einer Straße, auf der Radfahrer von Autofahrern mit allerlei Signalen dazu bewegt werden sollen, auf dem nicht benutzungspflichtigen, abgesetzten Radweg neben der Straße zu fahren, der allerdings nicht asphaltiert, sondern nur geschottert ist (was sich nach Regenfällen als wahre Freude erweist). Kann ich dieser Straße einen Tag wie bicycle=not_recommended zuweisen, damit ersichtlich ist, dass Fahrradfahrer hier zwar fahren dürfen, es allerdings wenig Freude macht, dort entlang zu radeln? Ich würde Empfehlungen nicht in die Datenbank einarbeiten; da geht es um eine sachgerechte, wenn auch für unsere Zwecke abstrahierende Beschreibung der Realität. Gibt es dazu bereits Alternativen oder Möglichkeiten, sowas darzustellen? smoothness=bad würde m.E. passen. Siehe auf http://wiki.openstreetmap.org/wiki/DE:Map_Features den entsprechenden Abschnitt. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] service=alley
Tobias Wendorff wrote: Hatto von Hatzfeld schrieb: Da kann man sehr schön sehen, wie sich die Heinrich-Blum-Straße (als residential) von diesen Seitenwegen unterscheidet. Die Straße ist breit genug für Gegenverkehr und auch zum Parken am Straßenrand und hat auch (niedrige) Bürgersteige. Diese Wege dagegen dürfen zwar auch von Autos befahren werden (und das geschieht auch); aber man muss dazu über den Bürgersteig fahren, und Begegnungsverkehr ist nicht oder nur bei sehr schmalen Autos möglich. Ich finde, dass highway=service mit ergänzenden service=alley (und access=yes oder access=destination) hier genau das richtige ist. Wofür ist es denn eine Zufahrt? Es ist keine Zufahrt zu einem einzelnen Gebäude, wie es mit service=driveway angegeben werden könnte, sondern ein schmaler Weg (eine Gasse), der dazu dient, die daran liegenden Grundstücke bzw. Gebäude zu erreichen. Auf http://wiki.openstreetmap.org/wiki/DE:Map_Features steht zu service=alley: Gasse, d.h. ein meist eher schmaler Weg, der zwischen Häusern oder Grundstücken hinein- oder hindurchführt (kann auch eine Sackgasse sein) und Zugang zu örtlichen Gegebenheiten bietet. Zu verwenden mit highway=service. Das passt hier genau. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google Maps - Link in OSM anzeigen?
Hatto von Hatzfeld wrote: Garry wrote: Gibt es eigentlich schon eine OSM Umsetzung die per CopyPaste einen Google-Maps Link als Kartenausschnitt in OSM darstellt? Ich habe mal etwas gebastelt, was in diese Richtung geht. http://www.salesianer.de/util/googlemap2osm.html Sehr simpel, aber vielleicht nützlich. Ich habe es jetzt noch um alle Seiten bzw. Funktionen erweitert, die mir im Moment bekannt waren. Damit lassen sich nun Map-Links zwischen OSM, Information Freeway, Cyclemap, ÖPNV-Karte, Googlemap, den Tools der Geofabrik, OSM Restriction Analyser, OpenStreetBugs, OpenRouteService austauschen, und sie lassen sich zum Editieren von OSM auch in Potlatch oder JOSM (mit aktivem Remote Plugin) öffnen. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schnittstelle zum Geobrowser der Autonomen Pr ovinz Bozen/Südtirol
Frederik Ramm wrote: peter.ranig...@rolmail.net wrote: Das gesamte Kartenmaterial ist frei von Lizenrechten, einzige Bedingung ist die Nennung der Quelle. Das klingt grundsaetlich gut, allerdings muesste man klaeren, was genau mit Nennung der Quelle gemeint ist. [...] Da muesste irgendjemand mal mit den zustaendigen Stellen reden und sich ein OK holen. Das möchte ich unterstreichen. Zu bedenken sind folgende Formulierungen, die auf diesen Seiten zu finden sind: Abgabe der Daten über Internet: die Daten können über Internet kostenlos für die Allgemeinheit bereitgestellt werden, soweit die Bestimmungen über den Datenschutz und eventuelle Nutzungs oder Eigentumsrechte von Dritten dem nicht entgegenstehen. Digitales Farborthofoto Ausgabe 2006: Die Landesregierung hat vom Eigentümer (CGR SpA) die Nutzungsrechte für die eigenen Ämter, die Gemeinden und andere öffentliche Institutionen in der Provinz erworben. Das Endprodukt wird als Bilddatenbank im Landes-GIS und auf DVDs bereitgestellt werden und kann auch an Non-Profit-Unternehmen abgegeben werden. Die Reproduktion oder Verwendung der Daten, auch auszugsweise, sind nur mit Angabe der Quelle (Titel, Herausgeber, für die Inhalte verantwortliche Dienststelle), Stand und Originalmaßstab. Die Lieferung der FarbOrthophotos in digitaler Form, 'it2000', welche von der Compagnia Generale Ripreseaeree S.p.a. aus Parma hergestellt worden sind, erfolgt auf Basis der Konvention gemäß Beschluß der Landesregierung Nr. 2978 vom 12.07.1999. So ganz klar scheint mir das mit den Nutzungsrechten nicht zu sein. Allerdings scheint mir eine Anfrage gute Aussichten auf Erfolg zu haben, da mit http://www.provinz.bz.it/raumordnung/download/BLRPreise2001.pdf dieser Behörde doch weitreichende Möglichkeiten zur Weitergabe der Daten gegeben sind. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service für Fußwege mit a ccess=foot?
Tobias Wendorff wrote:
Tobias Knerr schrieb:
vehicle=no folgt der im Wiki dokumentierten und üblichen Struktur für
Zugangsberechtigungen (Verkehrsmittel im Schlüssel, Zugangsrecht bzw.
Zugangsgruppe im Wert), [...]
Tagwatch-DE sagt:
vehicle = no = 65
access = foot = 46
Eindeutig finde ich das auch nicht gerade.
Dennoch finde ich, dass man das klare Schema
{Verkehrsmittel} = {Verkehrsart}
konsequent nutzen und Varianten wie access=foot vermeiden sollte.
Aber wie löst Du es, wenn Du Radfahrer und Fußgänger haben willst?
bike = yes, foot = yes? oder vehicle = no, bike = yes ?
Wenn schon, dann:
bicycle=yes
foot=yes
Das wäre aber nur bei highway=path (oder =cycleway) sinnvoll. Oder zusammen
mit access=no.
Nur bei einer sonstigen Straße (z.B. residential, unclassified, oder aber
zusammen mit access=yes) könnte man deine zweite Form nehmen:
vehicle=no
bicycle=yes
oder auch
motor_vehicle=no
horse=no
Gruß,
Hatto
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service für Fußwege mit a ccess=foot?
Georg Feddern wrote: Tobias Wendorff schrieb [über einen Zugang zum (S-) Bahnhof] Johannes Huesing schrieb: Wo besteht der Unterschied zwischen vehicle = no und access = foot ? Radio Eriwan: Ob Ihr Reittier S-Bahn fahren könnte oder nicht. ;-) Rein formal gesehen gelten Reittiere (Pferde, Esel, Ochsen, ...) weder als Vehikel noch als Fußgänger. Dann sollte man den Abschnitt Transport mode hierarchy auf http://wiki.openstreetmap.org/wiki/Key:access einmal entsprechend ändern - und außerdem noch die bicycle ergänzen und die deutsche Version anpassen. :-) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routable Garmin-Maps
Chris-Hein Lunkhusen wrote: Dermot McNally schrieb: [Turn-Restrictions] Wie ist das, wenn eine to oder from Straße gesplittet wird, dann sind doch plötzlich 2 ways in der to/from Rolle, oder? JOSM warnt davor - vermeiden kann ich das also dann, indem man die überflüssige Stücke sofort aus der Relation entfernt. Das Problem is wohl eher, dass die meisten Mapper sich mit Relations nicht gut auskennen, wenn überhaupt mit Restrictions. Tja, aber gerade für die Anwendung Routing wären exakte, korrekte Daten hilfreich. Vielleicht sollte man ab und zu einen Bot drüberlaufen lassen. ;-) Der Fehler, der durch dieses Splitten (einer vorher korrekten Restriction) entsteht, ist für das Routing nicht relevant, falls der Routing-Algorithmus halbwegs sinnvoll implementiert ist. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AOSM
Martin Koppenhoefer wrote: Am 6. März 2009 00:20 schrieb Frederik Ramm frede...@remote.org: Hatto von Hatzfeld wrote: Wenn hier kein Widerspruch aufkommt, dann werde ich auf der Seite http://wiki.openstreetmap.org/wiki/Aosm vermerken, dass die dortigen Informationen (zumindest derzeit) anscheinend nicht der Realität entsprechen. Ich hoere davon zum ersten Mal, aber die Person, die das da eingetragen hat, hat ja einen Usernamen, der fast wie eine Mailadresse aussieht - vielleicht einfach mal anmailen? gibt schon Neuigkeiten? Keine Reaktion, weder auf die Mail an diesen Usernamen noch auf die Webmail an den (laut gemappten Orten) entsprechenden OSM-Account. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google Maps - Link in OSM anzeigen?
Garry wrote: Gibt es eigentlich schon eine OSM Umsetzung die per CopyPaste einen Google-Maps Link als Kartenausschnitt in OSM darstellt? Ich habe mal etwas gebastelt, was in diese Richtung geht. http://www.salesianer.de/util/googlemap2osm.html Sehr simpel, aber vielleicht nützlich. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] AOSM
Irgendwie bin ich auf http://wiki.openstreetmap.org/wiki/Aosm gestoßen. Hörte sich vielversprechend an: Ein Programm, dass OSM-Kacheln anzeigen und bei GPS-Zugriff auch die eigene Position anzeigen kann sowie (über ORS) auch Routenplanung ermöglicht. Auf http://beta.arktosmobile.de/aosm/ findet man dann die Information, dass das Programm in eine Telefonbuchsoftware integriert ist, die Kartenfunktion jedoch auch ohne kostenpflichtige Aufrufe des Telefonbuchs nutzbar sei. Nach Installation auf meinem Handy, aber auch in der Demo http://beta.arktosmobile.de/webdemo.php findet sich aber gar keine Kartenfunktion. Was soll das also? Nur eine indirekte Werbung? Wenn hier kein Widerspruch aufkommt, dann werde ich auf der Seite http://wiki.openstreetmap.org/wiki/Aosm vermerken, dass die dortigen Informationen (zumindest derzeit) anscheinend nicht der Realität entsprechen. Auch http://wiki.openstreetmap.org/wiki/Software/Mobilephones wäre dann anzupassen. Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einschränkungen des OSM-Formats für Routing-Anwendungen?
Frank Glück wrote: ich hatte mich vor einiger Zeit schon mal näher mit OSM beschäftigt. Weil es damals noch hieß, dass OSM v.a. für Liebhaber von schön anzusehenden ausdruckbaren Karten gedacht wäre und es bei der Nutzung für Routing-Anwendungen aufgrund der Offenheit des Formats noch viele ungelöste Probleme bereite, hatte ich es damals erstmal wieder beiseite gelegt. 1. Bspw. soll es damals nach meiner Erinnerung wohl keine Möglichkeit gegeben haben, Brückenüberquerungen von Straßenkreuzungen zu unterscheiden, so dass auch an ersteren hätte abgebogen werden können. Wenn ich mir heute das Kartenmaterial ansehe, scheint dies inzwischen aber gelöst zu sein? Straßenkreuzungen: gemeinsamer Node beider Ways (Straßen) 2. Für Einbahnstraßen gibt es offenbar auch eine Kennzeichnungsmöglichkeit? oneway=yes (und anderes) 3. Wie sieht es mit Abbiegeverboten an Kreuzungen aus? Können solche angegeben werden? Und wenn ja, werden sie auch genutzt? http://wiki.openstreetmap.org/wiki/Relation:restriction 4. Kann man allgemein davon ausgehen, dass alles, was man menschlich aus einer fertig gerenderten OSM-Karte an verkehrstechnischen und -rechtlichen Gegebenheiten herauslesen kann, auch fürs Routing entsprechend auswertbar ist? Im Wesentlichen ja. Oder liegt der Fokus immer noch eher auf der Optik, so dass keine wirklichen semantischen Bezüge zwischen Aussehen und Funktionalität bestehen? Da müsstest Du jeden einzelnen Mapper fragen - natürlich ist für viele die Optik schon das wirksamste Feedback, so dass manchen nicht merken, wenn der Anschluss einer Straße an eine andere nicht funktioniert hat. Bei solchen routingrelevanten Dingen, die von den meisten Renderern nicht verarbeitet werden, wie etwa Geschwindigkeitsbegrenzungen, liegt der Erfassungsgrad m.E. noch recht niedrig. 5. Inzwischen gibt es ja offenbar schon einige OSM-Projekte, die sich ernsthaft mit dem Routing beschäftigen. Welche Erfahrungen habt Ihr damit? Welche Probleme wären hier noch zu nennen? Mitbekommen habe ich schon das hier in der Liste besprochene Thema Routing über Parkplätze hinweg. Ich nutze http://data.giub.uni-bonn.de/openrouteservice/ inzwischen schon regelmäßig :-) 6. Gibt es denn bei der Benutzung der Kennzeichnungen inzwischen mehr Einheitlichkeit und evtl. auch eine Instanz, die über die Einhaltung wenigstens der wichtigsten etablierten Standards wacht? Das ist weiterhin eine Art evolutionärer Prozess. Mutationen gibt es immer wieder; für die Selektion sorgen die Leute, die die Renderer konfigurieren oder Routenplaner und sonstige Anwendungen programmieren, aber auch die Mapper, denen bestimmte Mutationen (neue Map Features / Proposal) mehr oder weniger einleuchtend und nützlich erscheinen. :-) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap 3D als Webanwendung
Dirk Stöcker wrote: On Fri, 27 Feb 2009, Alexander Zipf wrote: wir haben angefangen zu untersuchen wie sich OSM-Daten für 3D-Web-Anwendungen nutzen lassen. Ein erster Prototyp ist nun testweise online verfügbar. http://www.osm-3d.org/ Das man sich mit dem Programm die Radieschen von unten anschauen kann ist lustig (ich würde es aber als Bug bezeichnen). Das ich nach 3 Minuten testen meinen Linux-Rechner neu booten musste, weil er total tot war ist weniger lustig (bin ich gar nicht mehr gewohnt). Hier (SuSE 10 für Dual Core) kein Problem. Und noch ein dritter Hinweis. Alle Umlaute werden bei mir als ý dargestellt. Das ist bei mir auch der Fall. Nicht im Suchformular, aber in der 3-D-Karte. Hängt wohl damit zusammen, dass mein PC mit UTF-8 als Standard läuft. Aber hübsch ist es. Ich schau bei Version 0.40 mal wieder vorbei :-) Nun - auch wenn es bis dahin noch einiges zu tun gibt, ist das schon ein sehr schöner Anfang. Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] surface=ground
Karl Eichwalder wrote: Was soll eigentlich dieses surface=ground bedeuten? Auf http://wiki.openstreetmap.org/wiki/Key:surface bzw. http://wiki.openstreetmap.org/wiki/DE:Key:surface stehen dieser und weitere Werte. Wird das im englischen sprachraum auch verwendet? Immerhin beispielsweise 99x in Großbritannien: http://tagwatch.stoecker.eu/Great_britain/En/tagstats_surface_ground.html Zum Vergleich alle Werte: http://tagwatch.stoecker.eu/Great_britain/En/keystats_surface.html Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gestrichelte Fläche in Braunschweig
Johannes Huesing wrote: hier kam kürzlich die Frage auf, ob sich da einer an einer Schraffur versucht hat: http://www.informationfreeway.org/?lat=52.273lon=10.59zoom=17 Ich habe mal einen Ortskundigen gefragt und er meint, das wäre schon ok so, er kann sich da an parallele Gräben erinnern. Auf http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlesatlon=10.59lat=52.273zoom=17 kann man das auch schön sehen. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Markieren von Rodelstrecken / Schlittelwegen
Marian Flor wrote: gibt es ein Zusatzattribut (evtl. auch erst im Status proposed), mit dem Feldwege (highway=track und bspw. tracktype=grade2) als Rodelweg bzw. Schlittelweg markiert werden können? Auf http://wiki.openstreetmap.org/wiki/Approved_features/Path finde ich: * snowmobile=designated * ski=designated Dementsprechend könnte man ja ergänzen: * sledge=designated Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald
Frederik Ramm wrote: Johannes Haller wrote: - Wald generell taggen mit natural=wood - fakultativ zusätzlich Baumbestand spezifizieren mit wood=deciduous/coniferous/... - fakultativ zusätzlich forstwirtschaftliche Nutzung landuse=forest Plus: landuse=forest impliziert natural=wood, und wir sind da, wo wir schon immer waren ;-) Mit der nicht unwichtigen Ausnahme, dass Mapnik beim Rendern das landuse=forest ignoriert, wenn natural=wood gesetzt ist. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsangabe in Namen (war Re: Kieser Training)
Sven Anders wrote: Hier in Hamburg haben alle Adressen als Ort Hamburg drin stehen. Das würde im Fall von McDonalds bedeuten, das ich eine Auswahl von (geschätzt) 50 Filialen den Namen McDonalds Hamburg haben. Das hat für jemanden der eine Liste bekommt (das muss nicht nur im Garmin sein, sondern bei jeder Umkreissuche nicht schön). [...] Deshalb denke ich das wir eine weiteres (optionales) Tag brauchen sowas wie name_with_position= oder unique_name. Man könnte das unique_name noch weiter aufspalten: name=Aldi loc_unique_name=Aldi Bahnhofstraße reg_unique_name=Aldi Buchholz Bahnhofstraße nat_unique_name=Aldi Buchholz (i.d.Nordheide) Bahnhofstraße world_unique_name=Aldi Buchholz (i.d.Nordheide) Bahnhofstraße Germany Keine schlechte Idee; aber zu viele verschiedene Tags machen die Sache nicht besser. Genügt nicht ein Tag unique_name in der lokalen Bedeutung? Möchte man einen überörtlichen eindeutigen Namen haben, dann kann der immer noch aus addr:city oder place:* geholt werden. Dein Vorschlag hat mich aber darauf gebracht, dass bei place:* vielleicht auch ein unique_name sinnvoll sein könnte, dann wohl am besten auf nationaler Ebene. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald
Frederik Ramm wrote: Hatto von Hatzfeld wrote: Mit der nicht unwichtigen Ausnahme, dass Mapnik beim Rendern das landuse=forest ignoriert, wenn natural=wood gesetzt ist. Das sind ein paar Zeilen in einem Configfile, davon sollte man sich nicht beeinflussen lassen bei der Entscheidung, was man richtig findet. Nein, aber man sollte das Configfile ändern :-) Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schleichwege und Funktionswege (Re: Routendarstellung in Openrouteservice)
Johann H. Addicks wrote: Und was ist mit den Wirtschaftswegen innerhalb von Autobahnkreuzen? Wenn man die mapt wie hier, dann geht das deutlich zu Lasten der Übersichtlichkeit: http://www.openstreetmap.org/?lat=50.1347lon=8.59285zoom=17layers=0B00FTF Das wird durch dieses weitere Beispiel bestätigt: http://www.openstreetmap.org/?lat=50.96921lon=7.03119zoom=17layers=B000FTF Da scheint aber auch das Rendering von Mapnik (im Gegensatz zu Osmarender) suboptimal zu sein. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchisches Tagging
Bernd Wurst wrote: Am Freitag, 13. Februar 2009 schrieb Dirk Stöcker: Derjenige, der sicht das ausgedacht hat, hat mal richtig mitgedacht :-) Nein, es fehlt die Variante für die Leute die das mit dem Taggen von Schilden völlig behämmert finden und nur die Info für den Router eintragen möchten. Ich sehe in den netten Schildern, die JOSM jetzt anzeigt, keine Entsprechungen von realen Straßenschildern, sondern eine leicht verständliche Darstellung der jeweiligen für das Routing gedachten restriction. Auf http://wiki.openstreetmap.org/index.php/Relation:restriction heißt es dementsprechend ja auch: There is no need to model no turning into the wrong way of a one way street - we take this for granted. Allerdings meine ich auch, dass für die Mapper auch eine Karte existieren sollte, auf der man die Restrictions sieht. Ohne ein solches, leicht zugängliches Feedback der eigenen Einträge werden zu wenige Mapper die Restrictions erfassen. Das Feedback nur über Routing-Fehler zu machen, genügt nicht. http://osm.virtuelle-loipe.de/restrictions/ ist sicher ein guter Ansatz; ob es reicht, weiß ich nicht. Besser wäre m.E. tatsächlich, wenn Osmarender die Restrictions zeigen würde. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Hatto von Hatzfeld wrote: Und wenn dann noch irgendwann auch foot=designated und bicycle=designated berücksichtigt werden, dann wird auch das Fußgänger- und Fahrrad-Routing in meiner Umgebung gut funktionieren :-)) Das scheint jetzt der Fall zu sein. Danke!!! Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kieser Training
Sven Anders wrote: Eins verstehe ich immer nicht, warum wird so ein Thema auf talk-de lang und breit diskutiert, anstatt vorher mit dem ursprünglichen Mapper darüber zu reden? Es gibt die History-Funktion und da kann man doch sehen, wer es war und dann einfach mal nachfragen. Sorry - an deren Nutzung muss ich mich noch gewöhnen :-) Und wenn man sich einig ist, korrigiert man einfach den Punkt und gut ist. Ein Konsens war auch mein Ziel. So, wenn niemand anders hier schreit, mache ich demnächst einen Korrekturlauf. Dabei könnte natürlich auch wieder was daneben gehen, vielleicht gibt es ja auch andere Freiwillige? Ich würde das ganze jetzt wie folgt ändern: name wird zu nat_name anschließend: name=Kieser Training Warum nicht alt_name? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellungen im Vorlagenmenü des JOSM
BroadwayLamb wrote: Gerrit Lammert schrieb: Ich verstehe die ganze Diskussion nicht. natural=wood bedeutet: Da stehen Bäume (die nicht aus Plastik sind) landuse=forest bedeutet: Dieses Gelände wird als Forst genutzt. D.h. in 90% aller Fälle treten (in D) beide Tags zusammen auf. Das ist völlig OK, da sie ganz unterschiedliche Dinge beschreiben. Das ist wie highway=secondary; surface=paved. Das wird auch in 90% der Fälle gemeinsam auftreten Danke, genau diese Aussage trifft nach meinem Verständnis den Punkt. Ein Baum ist ein Baum, ob da irgendwann einmal ein Förster ein Kreuz drauf malt, ist sicher auch interessant, ändert aber nichts an der Tatsache, dass eine Ansammlung von Bäumen nun mal ein Wald ist. Dem stimme ich voll und ganz zu. Es ist viel logischer. Sobald ich zuviel Zeit habe, werde ich meine Waldflächen nach genau diesem Schema wieder umtaggen. Wer hat eigentlich im OSM-Wiki in den deutschen Mapfeatures bei landuse=forest geschrieben: Nur vollkommen unbewirtschaftete Wälder (Urwaldzonen) sollten mit natural=wood getagged werden. Die Tags nie gleichzeitig verwenden.? Erstens steht im englischen Text nichts davon, un zweitens ist Urwald nicht mit natural woodland (trees) identisch. Sollte das Wiki hier geändert werden? Was denken OSMler anderer Sprachen darüber? In welcher Farbe rendert Mapnik eigentlich, wenn beide Tags gesetzt sind? ;) Damit die Frage (trotz Ironiesmilie) geklärt ist: So als ob nur natural=wood gesetzt wäre. Wenn man der obigen Logik aber folgt, dann ist dies ein Bug in Mapnik. Vermutlich ist dieser Bug der Grund für den Hinweis im OSM-Wiki. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorlagen in JOSM auf Deutsch
André Reichelt wrote: Dimitri Junker schrieb: irgendwie ist das mit den Vorlagn in Deutsch (Bundesstraße,...) nicht so das Gelbe vom Ei. Denn einerseits gibt es die Mapper die sich an die Tag-Namen gewöhnt haben, also primary,... aber auch für die anderen ist es inkonsequent. Die meisten Benutzer interessieren sich überhaupt nicht für die Tags. Das gilt jedenfalls für die 08-15 Benutzer. Diese können mit primary deutlich weniger anfangen als mit Bundesstraße. Ich würde im Vorlagenmenü (besser Vorlage als Vorgabe!) Einträge für sinnvoll halten, die beiden Interessen gerecht werden: für highway=primary: Straße 1. Grades (Bundesstraße) für highway=secondary: Straße 2. Grades (Landesstraße) für highway=tertiary: Straße 3. Grades (Kreisstraße) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kieser Training
MrJones wrote: Ich finde es gut von Kieser Training dass sie uns die Daten zur Verfügung gestellt haben. Ich kann beim besten Willen nichts negatives darüber finden. Hier ging es nur darum, dass meist neben Kieser Training auch Postleitzahl und Ort im Namen angegeben sind, so dass alle diese Angaben auch auf der Karte erscheinen. Es genügt m.E., wenn PLZ und Ort in addr:* stehen. Wer daraus eine Karte erstellen will, bei der alle Sportzentren mit voller Adresse stehen, der soll das meinetwegen tun; aber in den Namen gehört die Postleitzahl sicher nicht. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellungen im Vorlagenmenü des JOSM
Ich mache jetzt mal die Ingrid ... Hatto von Hatzfeld wrote: Wer hat eigentlich im OSM-Wiki in den deutschen Mapfeatures bei landuse=forest geschrieben: Nur vollkommen unbewirtschaftete Wälder (Urwaldzonen) sollten mit natural=wood getagged werden. Die Tags nie gleichzeitig verwenden.? Erstens steht im englischen Text nichts davon, un zweitens ist Urwald nicht mit natural woodland (trees) identisch. Sollte das Wiki hier geändert werden? Was denken OSMler anderer Sprachen darüber? Wenn man vom Englischen ausgeht, ist die Unterscheidung allerdings nicht mehr so eindeutig. Mein (rein englisches) Oxford-Wörterbuch meint, dass forest eine (large area of) land covered with trees (and often undergrowth) ist, ein wood (mit Artikel) dagegen eine area of land covered with growing trees (not so extensive as a forest). Nicht die Bewirtschaftung macht also den Unterschied, sondern die Ausdehnung. Ich fürchte, dass in Deutschland sich viele in der Interpretation durch die ethymologische Verwandtschaft von engl. forest und dt. Forst haben irreführen lassen. Da derzeit die Nutzung tatsächlich durcheinander geht, würde ich dafür plädieren, dass das Rendering geändert wird. Beide Tags sollten identisch oder zumindest ähnlicher gerendert werden. Und wenn jemand explizit bewirtschafteten Wald von anderem unterscheiden will, dann wäre das durch (andere) Zusatz-Tags auszudrücken. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kieser Training
Hallo! Heute habe ich auf der Karte von Bergisch-Gladbach einen Punkt gesehen, der unschönerweise so beschriftet war: Kieser Training 51465 Bergisch Gladbach Nachdem ich das korrigiert habe (was sollen die Adressdaten im name-Attribut, wenn sie schon in addr:* stehen?), fand ich noch weitere Nodes, zuletzt über 70 in germany.osm, bei den der Name Kieser Training um den Ortsnamen, meist aber auch um die Postleitzahl ergänzt ist. Interessanterweise haben anscheinend die meisten davon auch das Attribut created_by:fixbot (mit Datum 15.9.2008). Hat jemand die Möglichkeit, das automatisch zu reparieren? Und wäre das okay? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS-Server für das Ruhrgebiet
Karl Eichwalder wrote: Selbstverständlich hat das LVA das Copyright an den Bildern. Aber ein Copyright an den OSM-Daten können sie nicht bekommen. Allenfalls können sie sich wünschen, dass angegeben wird, dass die OSM-Daten die LVA-Bilder als Quelle haben. Erstellt unter Benutzung von LVA-Bildern oder irgendwie so. Das Problem liegt - wie bei ähnlichen Angeboten anderer Stellen mit Ausnahme des Oberpfalz-Projekts - wohl eher an Bestimmung wie der, die hier so formuliert ist: Die Nutzung für kommerzielle Anwendungen ist ausgeschlossen. Wer für OSM Luftbilder digitalisiert, tut dies aber - unter anderem - auch für kommerzielle Anwendungen. Und damit kann man die LVA-Bilder nicht als Quelle für OSM nutzen. So habe ich - als Nichtjurist - zumindest bisher die Argumentationen rund um die Verwendung von WMS-Diensten für OSM verstanden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eingänge von großen Gebäuden
Frederik Ramm wrote: Hallo, Johannes Haller wrote: Gibt es die Möglichkeit, Eingänge von sehr großen Gebäuden zu bezeichnen (damit der spätere Kartenbenutzer nicht einen Kilometer um das Gebäude herumfahren muß, um zu schauen, wo er 'reinkommt)? Möglichkeiten gibt es immer. Ich finde das hier gut: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings aber es geht auch das hier: http://wiki.openstreetmap.org/wiki/Proposed_features/building_entrance Und außerdem auch das hier: http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Angabe_einer_besonderen_Zufahrt Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OVL-Datei
Markus wrote: Hallo Bernd, Ich habe eine OVL-Wegepunkte-Datei bekommen... Die Datei hat die Erweiterung EXE, diese soll ich auf OVL ändern. Exe ist keine Wegpunkte-Datei. Sicher nicht. Vielleicht kannst Du die Datei mal anschauen? Sie stammt vom hiesigen Radwegebeauftragten, exe-Endung häbe sie wegen irgendwelchen Browserproblemen... Beispiel: Radweg Lauf-Gräfenberg: http://www.nefkom.net/b.zunner/Schnaitta/Laugrae.exe (alle Dateien haben eine exe-Endung) Das ist eine binäre OVL(Version2)-Datei. Wie man die konvertiert, hat jemand auf http://www.gps-forum.net/daten-fur-das-garmin-gps-gerat-konvertieren-teil-1-t326.html beschrieben: Das Umwandeln von Dateien im OVL-Format (ovl steht für Overlay), das von den digitalen Kartenprogrammen der Landesvermessungsämter stammt, ist für beide der obenstehenden Programme und auch für den Konverter von gpsies kein Problem, aber nur dann wenn sie im sogenannten ASCII-OVL Format vorliegen. Leider werden aber oft nur Files im binären OVL Format angeboten, von dem es auch noch vier unterschiedlich Versionen gibt, die Versionen 2,3,4 und 5. Dann wird die Umwandlung mühsamer. [...] kann man mit dem Dos-Programm top2gps http://ourworld.compuserve.com/homepages/rmerschel die binären OVL-Dateien (nur die Versionen 2 bis 4) ins PCX5 Format verwandeln und das PCX5 Format dann mit z.B. NH Toptrans [oder mit GPSbabel] ins gpx-Format. Ich habe es nicht ausprobiert; aber vielleicht hilft's ja. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Pascal Neis wrote: wie vielleicht der ein oder andere bereits bemerkt hat, habe ich es nun endlich wieder geschafft ein Update der Routing Daten auf openrouteservice.org durchzuführen. Sehr schön! Ein zeitnahes Update motiviert auch eher, mal zu prüfen, ob die routingrelevanten Tags in der eigenen Gegend auch stimmen. Trifft das mit den Updates eigentlich auch auf die Adresssuche zu? Ich habe den Eindruck, dass jüngere Daten (jedenfalls auf Hausnummern bezogen) da noch nicht berücksichtigt werden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Florian Lohoff wrote: Ich meine einen fehler gefunden zu haben. Bei der normalen Car (fastest) wird richtigerweise ein Footway gemieden. Wenn ich jedoch eine Avoid Area aufziehe die den weg laenger machen wuerde (Nicht unmoeglich) wird der Fußweg preferiert ... Kann ich bestätigen. Das gilt anscheinend sogar dann, wenn die Avoid Area nicht einmal den Weg länger machen würde, sondern lediglich auf einem Weg liegt, der bei der Routenberechnung als eine (etwas längere) Alternative in Frage käme. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ways ohne Anschluss
Jan Tappenbeck wrote: mir ist es schon öfters untergekommen, dass einige Anwender Ways in die Landschaft werfen ohne diese an andere anschließen. Hat nicht einer von Euch eine gute Idee soetwas beim Erstellen abzufangen? Mit dem Validator ist das wohl nicht gemacht - der ist ja freiwillig. Wäre es nicht gut, wenn Punkte, die am offenen Ende eines highways (nicht anderer Linien!) liegen und kein Attribut (wie noexit=yes) haben, im Editor (insbesondere in Potlatch) eine spezielle Farbe bekommen? Das würde zumindest die Chance erhöhen, dass man seine eigenen Fehler schneller bemerkt. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Hatto von Hatzfeld wrote: Florian Lohoff wrote: Ich meine einen fehler gefunden zu haben. Bei der normalen Car (fastest) wird richtigerweise ein Footway gemieden. Wenn ich jedoch eine Avoid Area aufziehe die den weg laenger machen wuerde (Nicht unmoeglich) wird der Fußweg preferiert ... Kann ich bestätigen. Das gilt anscheinend sogar dann, wenn die Avoid Area nicht einmal den Weg länger machen würde, sondern lediglich auf einem Weg liegt, der bei der Routenberechnung als eine (etwas längere) Alternative in Frage käme. Jetzt kann ich es nicht mehr bestätigen :-/ Pascual - hast Du etwas geändert? Aufgefallen ist mir an http://data.giub.uni-bonn.de/openrouteservice/?zoom=17lat=50.97868lon=7.04316 allerdings, dass dem Routing-Algorithmus die vor einigen Wochen erfassten Wege zwar bekannt sind, die Adressdaten dagegen der Adressensuche nicht. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Pascal Neis wrote: Die Daten für das Addressbuch (für die Addresssuche) werden nicht gemeinsam mit den Routing-Daten aktualisiert. Die Erstellung des Addressbuches ist etwas umfangreicher und dauert auch etwas länger. Ich plane aber derzeit mit Christof ein Update für die kommende Woche. Das ist ja schön. Dank für all Deinen Einsatz! Und wenn dann noch irgendwann auch foot=designated und bicycle=designated berücksichtigt werden, dann wird auch das Fußgänger- und Fahrrad-Routing in meiner Umgebung gut funktionieren :-)) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie deutsch muss man sein?
Martin Koppenhoefer wrote: ich halte way und node durchaus auch für übersetzbar, allerdings sieht man schon an diesem Thread, dass es doch unterschiedliche Auffassungen darüber gibt, wie genau man das machen sollte. ich finde Punkt (oder evtl. noch Stelle) für Node am Besten, da das die Dimensionen des Objekts veranschaulicht, abstrakt als Begriff im Deutschen ist, und auch geometrisch das richtige Fachwort ist. Dem folgend wäre Linie, Linienzug (meinetwegen auch Verbindung) für die ways passend. Polygon halte ich übrigens für komplett irreführend. Polygonzug wäre wohl richtig; dann ist aber Linienzug noch eher allgemein verständlich. Vgl. http://de.wikipedia.org/wiki/Polygonzug Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummen in Mapnik (was: Re: Hausnummern)
Heiko Jacobs wrote: Nachdem nun auch t...@h mit den richtigen styles Karlsruhe renderte, bin ICH eigenltich recht zufrieden mit dem Ergebnis... Inzwischen scheint ja auch Mapnik die Hausnummern zu rendern: http://www.openstreetmap.org/?lat=50.9907lon=6.99503zoom=17 Die Darstellung gefällt ganz gut. Zweifel habe ich aber, ob man die Linien addr:interpolation wirklich auch in Mapnik anzeigen soll. Zumindest könnte sie noch etwas dezenter sein; diese Information ist doch eher nur für Mapper und Router interessant. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=industrial
Markus Sperl wrote: Dankeschön! Eine andere Frage: Kann es sein, dass landuse=industrial bei mapnik mit sehr ähnlichen Farben wie landuse=residential gerendert wird? Ich erkenne leider kaum einen Unterschied... http://openstreetmap.com/?lat=48.14099lon=11.42141zoom=16layers=B000FTF Vielleicht liegt's am Bildschirm? :-) Aber der Unterschied ist wirklich nicht groß: Residential ist ein reines, helles Grau (RGB: #dcdcdc), Industrial ein fast gleich helles, aber etwas rotviolett getöntes Grau (RGB: #ded1d6). Man könnte tatsächlich den Unterschied ein bisschen stärker machen. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=toilets - Pisuar
Jan Tappenbeck wrote: mancher Orts gibt es öffentliche Pisuars - als Toiletten zu taggen wäre wohl etwas fehl am Platze. Naja, als Oberbegriff ist toilets ja doch nicht falsch. Abgesehen davon, dass man die Damenwelt in die falsche Richtung führen würde. Unterscheidet Ihr dieses ? Wie wäre es mit access=male? :-) Allerdings weiß ich jetzt nicht, warum Du ausgerechnet die polnische Schreibweise pisuar verwendest. Dann doch besser englisch urinal oder deutsch Pissoir. Persönlich werde ich mich aber attraktiveren Objekten des Mappens zuwenden :-) Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=toilets - Pisuar
Jan Tappenbeck wrote: mancher Orts gibt es öffentliche Pisuars - als Toiletten zu taggen wäre wohl etwas fehl am Platze. Abgesehen davon, dass man die Damenwelt in die falsche Richtung führen würde. Warum nicht für Damen? Schau mal hier: http://flickr.com/photos/luckyfly/375027206 http://en.wikipedia.org/wiki/Female_urination_device Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum Nachbarmapper
Johannes Haller wrote: Wie kriege ich Kontakt zu einem Mapper, der in der selben Gegend wie ich die Karte verbessert? Ich sehe nur die Änderungen und finde den Nicknamen des Mappers. Unter nearby users auf der Karte in meinem Profil taucht er nicht auf. Unter users in Germany, dieser Liste im Wiki, scheinen auch nur Bruchteile der deutschen Beitragenden zu stehen. Probiere es unter diesen beiden Links (wobei $NICK entsprechend zu ersetzen ist): http://www.openstreetmap.org/user/$NICK (dort ggf. send message) http://wiki.openstreetmap.org/index.php/User:$NICK Wenn beides nicht weiterführt, dann will er wohl keinen Kontakt :-/ Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum Nachbarmapper
Nop wrote: Johannes Haller schrieb: Sorry, Rolf, falls ich Tomaten auf den Augen habe, aber ich weiß nicht, wie ich auf seine Benutzerseite gelangen kann... Ich habe auch ewig rumgesucht und mich gewundert, wieso die Anderen mir was schicken können aber ich keinen Link finde, mit dem ich eine Nachricht schicken kann. Ein Link Nachricht Senden, einen anschließend zur Eingabe eines Usernamens auffordert, wäre eine bedeutende Erleichterung für alle Neueinsteiger. Da könnte man vielleicht wirklich etwas in der Richtung machen. Vielleicht auch in JOSM (oder gibt es das schon?). Bisher geht ein Weg so: Auf OSM einloggen, fraglichen Kartenausschnitt anzeigen (nah heranzoomen!), Data-Layer aktivieren, das fragliche Objekt auswählen, Details anklicken, den Link hinter Edited by anklicken, und schon ist man auf der User-Seite, wo man dann send message auswählen kann. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Link zu Openrouteservice.org?
Sven Geggus wrote: Pascal Neis n...@geoinform.fh-mainz.de wrote: der Feature-Wunsch ist auf ORS online und beschrieben unter: http://wiki.openstreetmap.org/wiki/OpenRouteService#RouteLink_only_with_Start_or_End_Position Wow! Just in Time. lang=de funktioniert aber offensichtlich noch nicht so recht. Kann man den nicht angegebenen Punkt (am besten leer) und den Kartenausschnitt irgendwie beeinflussen? Wär schön wenn der angegebene Start oder Zielpunkt darin zu sehen wäre. Siehe http://wiki.openstreetmap.org/wiki/OpenRouteService#PermaLink Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Lizenz
Tobias Wendorff wrote: Frederik Ramm schrieb: Du hast aber meine Aussage aus dem Kontext gerissen. Du ebenso ... das war ein Absatz mit einem :-) dahinter. Es braucht also entweder einen Vertrag oder ein geltendes Gesetz. Wobei das eine von der Staatsanwaltschaft und das andere von Zivilanwälten ausgetragen wird :-) Es gibt gesetzliche Schadensersatzansprüche, die auch ohne die Grundlage eines Vertrages gelten. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maßstabsbalken zu klein
Florian Arnold wrote: ist eigentlich schon mal jemandem von euch aufgefallen, dass der Balken mit den Längenangaben links unten auf der Slippy Map deutlich falsche Werte zeigt? Mir sind die Längenangaben schon immer seltsam groß vorgekommen, dann habe ich mal mit Google verglichen. Ergebnis: Der Balken auf OSM ist um ca. den Faktor 1,5 kürzer bzw. die Zahlen größer. Mache denselben Versuch doch auch mal hier: http://www.openstreetmap.org/?lat=-0.0867lon=-78.46644zoom=17 Und dann suche eine Erklärung für das Ergebnis :-)) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Ulf Lamping wrote: Mario Salvini schrieb: Für die kleineren Inseln z.B. für die sicherere Überquerung einer Straße gibts doch crossing=*. Jedesmal direkt 2 Einbahnstraßen draus machen macht keinen Sinn, weil man sonst auch Turn-Restriction-Relation setzen muss. Ansonsten meint der Router er könnte da links abbiegen was ja in den meisten Fällen Blödsinn ist. Ob man die Verkehrsinseln einzeichnest oder nicht ist mir persönlich jetzt recht egal. Aber bitte nicht im Nebensatz neue Behauptungen aufstellen: Wenn du 2 Einbahnstraßen draus machts, brauchst du keine turn-restrictions zusätzlich anzulegen. Die ergeben sich automatisch aus den Einbahnstraßen und ein Router wird die Einbahnstraßen schon in seine Route einbeziehen. Ich freue mich schon auf die Navigationsgeräte, die mir vor jeder Verkehrsinsel sagen: Jetzt (halb)rechts abbiegen. ;-/ Hier spielt m.E. wieder das Kriterium Abstraktionsgrad eine Rolle. Oberflächlich gesehen mag das Taggen als 2 kleine Einbahnstraßen einen höheren Informationsgehalt haben; aber für Anwendungen in dem für OSM typischen Abstraktionsgrad - und zwar sowohl für Router wie für Karten - hat ein passendes Tag crossing=* einen höheren Informationswert als die zwei Einbahnsträßchen. - Die Leistung des Kartographierens liegt ja in der Abstraktion, im Erfassen der wesentlichen Informationen und Weglassen der unwesentlichen. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Bernd Wurst wrote: Da sind wir doch froh, dass bei OSM so viel Multi-Kulti-Suppe zusammenkommt. Es gibt die richtigen Kartographen, die wissen wie man Karten schön macht, es gibt die Abtraktionskartographen, die nur das einzeichnen wollen was ein Navi braucht um eine Route sinnvoll anzusagen. Aber, und das ist auch wichtig, es gibt noch mehr. Es gibt z.B. unglaublich viele Leute die Zugriff auf die Rohdaten haben und eine Transformation und Konversion ist nach belieben erlaubt und möglich. Das unterscheidet unseren Datenbestand von den Alternativen. Ein Navi das auf OSM-Daten arbeiten will, muss entweder ein bisschen intelligenter sein (es geht hier nur halb rechts, also sagt man nichts an, Wenn man 20 Meter weit sehen kann, wird klar was gemeint ist, also sagt man nichts an) oder es braucht eine passende Vor-Verarbeitung. Die Vor-Verarbeitung ist in ganz vielen Fällen algorithmisch machbar. Daher sollte sie auch so gemacht werden und nicht schon im Kopf der Mapper. Unser Ziel sollte es sein, alle Informationen in der Datenbank zu haben, aus der man mittels algorithmischer Methoden alles errechnen kann was man haben will. Okay - Du hast mich weitgehend überzeugt. Soll von mir aus jeder, der es will, aus jeder Verkehrsinsel zwei Einbahnstraßen machen. Grade die genannten kurzen oneway-Stückchen kann man für Routing-Ansagen ohne weiteres prima aussortieren. Sie irgendwie drin zu haben erhöht aber wesentlich die Schönheit und auch die realitätstreue der Karten. Das mit der Ästhetik ist so eine Sache. De gustibus ... Ciao, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BAB - Beginn der Verzögerungsspur
Fips Schneider wrote: [...] leider weiss ich grade nicht, wie man das als 'nicht für LKW' taggt. (Kann das jmd machen oder mir erklären, wie das 'richtig' geht?) hgv=no Siehe http://wiki.openstreetmap.org/wiki/Key:access Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radwege auf Bahntrassen
Rotbarsch wrote: Das note-Tag finde ich nicht überaus geeignet fürs erkennen von Bahntrassenradwegen, ebensowenig wie Relationen, so dass ich mich jetzt für oder gegen die Bahnhistoriker entscheiden werde: Für heißt wohl sowas wie highway=cycleway, railway=dismantled (dies kommt in dem von Fred erwähnten englischen ML-Beitrag vor). Gegen würde heißen highway=cycleway, cycleway=disused_railway Letzteres gefällt mir, weil es für die Renderer aufwärtskompatibel ist und andererseits jeder, der eine spezielle Karte machen will, damit ein klares Tag hat. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] smoothness-Tag
Hi! Schon seit einiger Zeit habe ich einen Tag gesucht, mit dem sich erfassen lässt, ob ein Weg z.B. mit Inline-Skates oder mit einem Rennrad befahren lässt. Vor kurzem bin ich auf den Tag smoothness gestoßen, der mir dafür auch recht geeignet scheint, da er angeben soll, für welche Fahrzeuge ein Weg nutzbar ist. Hier die Tabelle von Werten, wie sie in den Map Features steht: smoothness: usable by: excellent roller blade, skate board and all below goodracing bike and all below intermediatecity bike, sport car, wheelchair, scooter and all below bad trekking bike, normal cars, rickshaw and all below very_badCar with high clearance, mountain bike without and all below horribleoff-road vehicles and all below very_horrible Tractor, ATV, tank, trials bike, mountain bike with studded tires and all kind of off-highway vehicles (see also mtb_scale=*) impassable No wheeled vehicle (see also sac_scale=*) Anscheinend wurde darüber auch mit positivem Ausgang abgestimmt. Es scheint sich dann aber ein Edit-War entwickelt zu haben, in dessen Folge nun die Seite http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness nach http://wiki.openstreetmap.org/wiki/Rejected_features/Smoothness verschoben wurde, wo der Status aber immer noch als Approved angeben ist. Auf http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Smoothness kann man das unten nachlesen. Ich kann nur sagen, dass mir dieser Edit-War missfällt und ich bisher keinen besseren Vorschlag als die obigen Tags (die natürlich ihre Grenzen haben) gesehen habe. Wie wird der Tag denn von den Lesern dieser Mailingliste gesehen? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Nop wrote: Die 3 Aussagen stehen einfach im Widerspruch: - designated = exclusive (path Proposal) - footway = mainly (Map Features) - footway == path + foot=designated (Map Features) Im Path-Proposal steht: access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. Dem kann ich nicht entnehmen (und auch keiner anderen Stelle im Proposal), dass designated irgendeine Art von exklusiver Nutzung durch die damit versehene Verkehrsteilnehmergruppe meint. Das Wort exclusive kommt im ganzen Proposal nicht vor. Woher kommt also diese Interpretation? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [JOSM] - Verbesserung: measurement-plugin
Tobias Wendorff wrote: Die Performance ist sehr gut - ich verwende kein Vincenty! Mehr dazu (Formeln + Sourcecode) werde ich in den kommenden Tagen veröffentlichen. Auch die Berechnung der Polygone habe ich komplett überarbeitet und sie ist nun sehr genau. Multipolygone konnte ich leider noch nicht integrieren (kompliziert). Download: http://raumplanung.tobwen.de/OSM/JOSM/measurement.zip Bitte testen und reporten :-) Habe es kurz getestet, auch wenn ich bisher gemeint hatte, so etwas nicht zu brauchen. Es funktioniert noch intuitiver als ich dachte - schon beim bloßen Auswählen eines oder mehrerer Ways bzw. einzelner Flächen werden die Maße angezeigt (habe es allerdings nicht mit riesigen Datenmengen getestet). Sehr schön! Es ist damit auch nützlicher als ich dachte, und ich werde es aktiviert lassen. Erst nach einiger Zeit habe ich allerdings kapiert, dass Winkel nur angezeigt werden, wenn (sinnvoller zwei) einzelne Nodes markiert sind. Gemeint ist damit anscheinend die Neigung der Verbindungslinie beider Nodes gegenüber dem Längengrad (d.h. der Nord-Süd-Achse). Einige Effekte sind mir dagegen unklar geblieben: Warum wird als Weglänge (bei mir) immer 0 angezeigt? Unter Auswahllänge wird (bei Markierung von Ways) ja der vermutlich richtige Wert angezeigt, wie auch bei der Markierung zweier Nodes. Bei der Auswahl mehrerer Flächen werden die Längen der Umfassungslinien addiert, die angezeigte Auswahlfläche ist aber nur die von einer der ausgewählten Flächen (diese scheint auch willkürlich ausgewählt zu sein). Das finde ich inkonsistent. Was passiert, wenn man mehr als 2 Nodes selektiert? Der angezeigte Winkel wird anscheinend aus zwei Nodes berechnet, die scheinbar willkürlich unter diesen ausgewählt werden. Wie die dann angezeigte Auswahllänge zu interpretieren ist, das habe ich überhaupt nicht herausgefunden. Noch komplizierter wird es, wenn man gemischt selektiert. Soweit mein Feedback. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] nochmal Archologie
Jan Tappenbeck wrote: in http://wiki.openstreetmap.org/wiki/DE:Tag:historic%3Darchaeological_site stehen für site_type nur ENGLISCHE begriffe - gibt es für GROSSSTEINGRAB keines ??? Nimm halt megalith_type=dolmen, wenn Du es englisch haben willst. Siehe http://en.wikipedia.org/wiki/Dolmen Sobald - und das dürfte dann bald so sein - megalith_type=dolmen häufiger vorkommt als megalith_type=Großsteingrab, kannst Du ja die Wiki-Seite http://wiki.openstreetmap.org/wiki/DE:Tag:historic%3Darchaeological_site entsprechend ändern. :-) Überhaupt könnte jemand mal die englische Version dieser Seite etwas mehr beleben :-)) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [JOSM] - Verbesserung: measurement-plugin
Tobias Wendorff wrote: danke für dein Feedback. Hatto von Hatzfeld schrieb: Erst nach einiger Zeit habe ich allerdings kapiert, dass Winkel nur angezeigt werden, wenn (sinnvoller zwei) einzelne Nodes markiert sind. Gemeint ist damit anscheinend die Neigung der Verbindungslinie beider Nodes gegenüber dem Längengrad (d.h. der Nord-Süd-Achse). das kommt noch vom Originalprogrammierer. Was wäre für Dich denn angebrachter? Zum ersten: Dieser Winkel könnte auch angezeigt werden, wenn ein Way markiert ist (statt zweier Nodes); in diesem Fall könnten die beiden Endpunkte des Ways genommen werden. Zum zweiten: Bei Winkel hatte ich zuerst an den Winkel gedacht, den ein Way an einem bestimmten Node bildet. Vielleicht könnte man einen solchen Winkel genau dann errechnen, wenn genau ein Way und einer von dessen Nodes (der kein Endnode ist) markiert sind. :-) Und nun übersteigere ich das noch zu einer anderen Idee: Wenn ein Way und zugleich ein Punkt außerhalb des Ways markiert ist, dann könnte Weglänge den (Minimal-)Abstand vom Punkt/Node zum Way/Weg angeben :-)) Vorsicht - vielleicht komme ich auf noch mehr Ideen! Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Ulf Lamping wrote: Wenn die Situation vor Ort wirklich so ist, daß dort nicht mal die allerersten Anzeichen einer Bautätigkeit vorhanden sind, dann ist sowohl highway=construction als auch construction=yes objektiv Blödsinn. Wäre dann nicht so etwas wie highway=planned oder planned=yes angemessen? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Sven Sommerkamp schrieb (als Antwort auf meinen Thread-Start): [6] http://www.openstreetmap.org/?lat=50.91985lon=7.02348zoom=17 [7] http://de.wikipedia.org/wiki/Polygonzug Butter bei die Fische. Die Autobahn drehen wir zurück, oder? Konsens? Nein. Wie ich bereits anderswo schrieb, hatte ich mich da geirrt - dort sind die Fahrbahnen tatsächlich physisch durch Grünstreifen getrennt. Von meinen grundsätzlichen Anmerkungen zum Thema will ich damit aber nichts zurücknehmen :-) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Bugs schließen
Ulf Lamping wrote: BTW: Was machen wir mit unklaren Einträgen, bei denen keiner drauf reagiert? Ich hab da z.B. http://josm.openstreetmap.de/ticket/1559 bei dem ich auf meine Frage seit einem Monat keine Rückmeldung bekomme. Was er meint, ist mir schon klar. Zum Beispiel bei meinem JOSM (Version 1206): highway=$X; foot=designated wird als Fußweg angezeigt highway=$X; foot=designated; bicycle=designated wird als Fußweg angezeigt highway=$X; bicycle=designated wird als $X angezeigt Auch eine Ergänzung mit motorcar=designated ändert daran übrigens nichts. Das ist zumindest inkonsequent, und in der Praxis relevant wird es, wenn für $X path oder cycleway gewählt wird. Meines Erachtens sollte der Highway-Tag Vorrang haben. Übrigens auch beim Rendern in Mapnik Co. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Hallo, Leute! Hier etwas, was ich schon länger loswerden wollte, aus aktuellem Anlass und wegen des regnerischen Sonntags aber nun endlich schreibe: Nach einiger Beobachtung sehe ich jetzt in einigen Aspekten dessen, was und wie inzwischen von engagierten Mappern erfasst, OpenStreetMap in einer gewissen Krise - wobei ich unter Krise, gemäß dem Ursprung dieses Wortes, eine sich verschärfende problematische Situation verstehe, die zu einer Entscheidung drängt: Da gibt es einerseits - auch in Deutschland - noch viele Gebiete, in denen höchstens die Überlandstraßen erfasst, innerörtliche Straßen aber kaum zu finden sind [1]. Andererseits ist an bestimmten anderen Stellen, vor allem in Städten, schon so viel gemappt, dass Mapper sich schon daran gemacht haben, dort jedes einzelne Haus, jede Kneipen und jeden Recycling-Container zu erfassen [2] ... oder jedes Gehege im Zoo [3], jeden Fußweg auf einem Friedhof [4] oder jedes Becken einer Kläranlage [5]. Es ist auch nichts dagegen zu sagen, wenn Mapper sich auf diese Weise (oder auch z.B. durch das Erfassen von Hausnummern) um größere Detailtreue in ihrer Umgebung bemühen, falls es ihnen nicht möglich oder zu aufwändig ist, sich in noch wesentlich weniger erfassten Gegenden zu betätigen. Problematisch wird das Ganze, wenn die Abstraktionsebene des Projektes verlassen wird. Das geschieht z.B., wenn einige bereits damit beginnen, einzelne Spuren einer mehrspurigen Straße getrennt zu erfassen (obwohl diese Teil einer Fahrbahn sind und man real zwischen den Spuren durchaus wechseln kann). Ein Beispiel, auf das ich heute gestoßen bin, ist die A 559 bei Köln [6]. Das Ergebnis des Renderns ist durchaus unbefriedigend, und man kann das hier auch nicht dem Renderer zuschreiben. Bei OpenStreetMap gibt es, wie man aus der Entstehung und auch aus der noch (!) überwiegenden Praxis erschließen kann, folgende Abstraktion: Jeder Weg (ob Straße, Rad-, Fußweg etc.) wird in der Datenbank grundsätzlich als Polygonzug [7] erfasst, unabhängig von der physikalischen Breite des Weges oder der Anzahl seiner Fahrspuren, also nicht als Fläche. Das ist auch eine gute Wahl, wenn man sie von der Nutzung der Daten her betrachtet: Es geht bei den Wegen um die Verbindung zwischen Orten. Für das Visualisieren (Rendern) ist z.B. das (bei unseren Datenquellen zudem immer recht ungenaue) Mappen einzelner Spuren eher kontraproduktiv, wie das obige Beispiel [6] zeigt - die zusätzlichen geokodierten Nodes haben eine Pseudogenauigkeit, deren wahre Ungenauigkeit visuell nun deutlich hervortritt. Und selbst wenn der Renderer nun noch die Information bekäme, dass es sich um eine gemeinsame Fahrbahn (und Brücke) handelt und der Wechsel zwischen den Spuren erlaubt ist, dann ist gegenüber einem einfachen Polygonzug (way), der mittels zusätzliche Tags mit der Information über die Zahl der Spuren versehen ist, keinerlei Informationsgewinn zu verzeichnen; es ist nur die Sache für die Renderer und die Routingsoftware erschwert. Nun mag mancher erwidern: Wir mappen doch nicht für die Renderer und Router. Da ist etwas Wahres dran; es wird aber zu oft als Totschlagargument gebraucht. Es trifft vor allem zu, wenn jemand versucht, Bugs oder auch Unzulänglichkeiten der Renderer beim Mappen auszugleichen - da ist es besser, richtig zu mappen und die Darstellung dann der jeweiligen Software zu überlassen. Richtig mappen heißt aber nicht, jeden Bordstein und jede Linie zwischen zwei Fahrspuren derselben Fahrbahn in ihrer Lage zu erfassen, sondern den Zweck von OpenStreetMap zu beachten. Der liegt nun mal in einer Karte, zu deren Abstraktionsgrad nun einmal gehört, einen Weg (Straße) als Verbindung (Polygonzug) zu erfassen und diese Information (wo ist A und B und wie komme ich von A nach B) möglichst gut darzustellen (sei es als Karte oder per Routingsoftware oder wie auch immer). Und wenn z.B. die Breite oder Zahl der Spuren (einschließlich ihrer Abbiegemöglichkeiten) einer Straße in diesem Rahmen eine sinnvolle Information sind, dann sollte man sie als Eigenschaften (Tags) der entsprechenden Straße zuschreiben. Das ist dann der richtige Abstraktionsgrad - im Gegensatz zur Pseudogenauigkeit von in die Gegend gesetzten Nodes mehrerer Spuren. Um schließlich noch ein Beispiel zu ergänzen: Für kontraproduktiv halte ich es auch, wenn jeder zu einer Straße parallele Radweg als eigener Polygonzug (Way) gemappt wird und man dann eventuell jeden abgesenkten Bordstein, über den man vom Radweg auf die Fahrbahn wechseln könnte, erfassen will. Da sollte man sich immer fragen, wer denn diese Information nutzen kann: Kein Radfahrer wird doch je auf einer Karte nachschauen, wann denn ein solcher Bordstein kommt. Und für die Routenplaner genügt es, wenn an den Kreuzungen erfasst ist, wie man in welche Richtung weiterfahren kann. Überhaupt genügt es (und mehr wäre eine Überforderung!), wenn eine Karte oder eine Navigationssoftware mir einen recht guten Weg (im Sinn der Folge von Straßen, die ich fahren oder begehen muss) angibt -
Re: [Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Chris-Hein Lunkhusen wrote: Hatto von Hatzfeld schrieb: Problematisch wird das Ganze, wenn die Abstraktionsebene des Projektes verlassen wird. Das geschieht z.B., wenn einige bereits damit beginnen, einzelne Spuren einer mehrspurigen Straße getrennt zu erfassen (obwohl diese Teil einer Fahrbahn sind und man real zwischen den Spuren durchaus wechseln kann). Sehe ich genauso. Wenn jemand wie oben beschrieben gemappt hat, dann würde ich das als fehlerhaftes Mapping betrachten, es sei denn im Wiki steht etwas anderes. Getrenntes Mapping bitte nur bei baulich getrennten Spuren. Jetzt ist mir aufgefallen, dass in diesem Fall doch richtig gemappt wurde. Die Spuren sind dort tatsächlich baulich getrennt - ich hatte das mit einer Kreuzung weiter nördlich verwechselt. Peinlich, dass ich mich da geirrt habe; und zur Ehrenrettung des dortigen Mappers will ich das hier auch zugeben. An meinen grundsätzlichen Überlegungen zum Thema will ich aber festhalten. Und was Tobias Knerr dazu geschrieben hat, ist wohl hier das dringliche: Wir brauchen ein gescheites Konzept zur Erfassung von Spuren. Diese sollte nicht durch das Setzen zusätzlicher Nodes geschehen, sondern durch Tags (im Way oder in einer Relation). Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
André Reichelt wrote: Ich halte es durchaus für sinnvoll, wenn man auf mittlere Sicht dazu über geht, anstatt einfacher Linien wirklich jede Fahrbahn separat einzuzeichnen. Man sollte sogar noch weiter gehen und sämtliche Objekte der realtät entsprechend als Flächen erfassen. Außerdem sollte man davon weg kommen, mit Linien zu arbeiten und auf Kurven ausweichen, da diese weit realistischer sind. [...] Auf jeden Fall ist es der falsche Weg, sich an irgendwelchen technischen Grenzen bei der Verwertung fest zu klammern. Abstraktion ist nicht eine Beschränkung aufgrund technischer Grenzen, sondern eine Interpretation der Wirklichkeit, eine bewusste Auswahl wesentlicher Informationen und deren Unterscheidung von den eben nicht relevanten Informationen. Abstraktion ist also eine echte menschliche Leistung, und daran will ich hier wirklich festhalten. Eine höhere Detailtreue ist keinesfalls immer ein Gewinn, sondern kann auch einen Verlust an Nutzen bedeuten, und das nicht nur bei einer gedruckten Karte. Und selbst wenn es einmal Smart Phones und andere mobile Rechner geben sollte, die die Daten von ganz Deutschland einschließlich aller Fahrspuren, Bordsteinabsenkungen, Grünstreifen zwischen Fahrbahnen und Radwegen, Hundekotbeutelverteiler, Pflastersteinen, Kanaldeckeln etc. nicht nur speichern, sondern auch in Echtzeit für das Routing auswerten können, dann braucht man immer noch Mapper, die diese Daten nicht nur eingeben, sondern dauerhaft auf dem aktuellen Stand halten. Ich sehe die Grenze in dieser Frage also nicht in der Technik, sondern im Nutzen der Daten und in den freiwillig engagierten Mappern. OSM ist auf eine breite Basis an Interessenten für diese Daten angewiesen, denn nur solche, für sie relevanten Daten werden von ihnen auch in großem Umfang erfasst werden. Wenn - z.B. aufgrund der Erfassung einer großen Menge an den Details (m.a.W.: durch die Senkung des Abstraktionsniveaus) - die Repräsentation eines Straßenstücks (oder sonstigen Objektes) in der Datenbank zu komplex ist, als dass sie ein einfacher Nutzer bei Bedarf korrigieren kann, dann wird die Gefahr groß, dass niemand Änderungen hier auch einpflegt. Auch daher mein Plädoyer für eine gewisse Bescheidenheit. Wir brauchen auch in Zukunft eine genügend niederschwellige Möglichkeit zum Mitmachen (und zwar nicht nur bei OpenStreetBugs, dessen Meldungen dann ja doch jemand in der Datenbank umsetzen muss.) Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Addresssuche - Zuordnung der Straße Was : News auf ORS
Gerd v. Egidy wrote: Wie wäre es damit: In alle Richtungen rund um den Node (oder den Schwerpunkt wenn building aus mehreren Nodes) die nähsten Straßen herausfinden. Es gilt jeweils die kürzeste Distanz zu einer Straße. Abstand Hausnummer - nächstgelegene Straße: d1 Abstand Hausnummer - zweitnächstgelegene Straße: d2 Wenn d2 / d1 x dann die Hausnummer der nächstgelegenen Straße zuordnen, ansonsten kein Treffer. Mindestens bei kleinen Werten von d1 wäre das problematisch. Bei Häusern an Straßenecken habe ich - wie vermutlich auch andere - nur darauf geachtet, dass der Node wenigstens minimal seiner Straße näher liegt als der anderen Straße. Im Übrigen meine ich, dass Adressnodes, die sehr weit weg von ihrer Straße liegen, zur Sicherheit immer ein addr:street bekommen sollten. Der Adressalgorithmus sollte aber die Position des Nodes auswerfen und nicht den nächstgelegenen Punkt der entsprechenden Straße. Zumindest in dem Fall, dass es einen exakten Treffer gibt oder der Wert aus addr:interpolation ermittelt wurde. Wenn dagegen selbst interpoliert werden muss (also kein exakter Treffer und auch kein addr:interpolation vorhanden ist), dann wäre vielleicht doch ein Ergebnis in Straßennähe sinnvoll. Wenn nämlich Adressnodes gesetzt werden, dann ist es die Verantwortung des Mappers, ihn dorthin zu setzen, wo der physikalische Zugang besteht. Das kann manchmal auch an einem namenlosen Service-Weg oder an einer Straße sein, die einen anderen Namen trägt als den in addr:street genannten. Der Suchalgorithmus sollte die Position des gefundenen Nodes dann nicht verbessern (ein Beispiel, wo das schief ging, habe ich gestern gepostet); vielmehr sollte es dem Routingalgorithmus überlassen bleiben, einen geeigneten Weg zu finden. Nur so hat der Mapper die Gestaltungsmöglichkeit, durch die Positionierung des Nodes den passenden Zugangsweg deutlich zu machen. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf ORS
Marc Schütz wrote: Hatto schrieb: Zur vereinfachten Demo habe ich hier einmal den Weg von der echten Position des Adress-Nodes zu der mit der Suche ermittelten Position Im Weidenbruch 46, Köln verlinkt: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=7.0278436,50.979942end=7.0278114,50.9803202pref=Shortestlang=de Ich glaube, dein Fall ist eher die Ausnahme. Normalerweise gehört ja ein Haus zu der Straße, in der es den Eingang hat. Für Fälle wie diesen sieht das Karlsruhe-Schema eine Relation vor (die wahrscheinlich von ORS noch nicht ausgewertet würde): http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Giving_hints_about_the_road-access_.28optional.29 In die deutsche Übersetzung dieser Seite habe ich diese Möglichkeit eines Hinweises auf einen Zugang nicht eingebaut, weil ich den englischen Text nicht verstanden habe. Vielleicht könnte mir (oder besser noch: im Wiki) jemand mal erklären, welcher way da als accessto in die Relation aufgenommen und ob denn nicht irgendwie auch der Adress-Node eingebaut werden soll. Oder steht da einfach nur versehentlich way statt node? Was für ein und warum überhaupt irgendein Weg als accessfrom einzutragen ist, ist mir im Übrigen auch nicht klar, vor allem wenn es nur eine Zufahrt gibt. Im Übrigen kommt es hier in Köln recht oft vor, dass der Zugang zu einem Haus von einer anderen Straße aus geht - wenn auch meist nur bei Häusern an einer Straßenecke und damit nur um ein paar Meter daneben und nicht so weit entfernt wie im oben geschilderten Fall. Im obigen Fall muss ich übrigens den access-node fast auf dieselbe Stelle setzen wie den adress-node, was auch sehr wenig intuitiv ist. Da wäre es m.E. sinnvoller, wenn man die Sache umdreht, d.h. wenn der Suchalgorithmus immer die nächstliegende Straße nimmt (unabhängig von deren Namen) und man im Fall, dass der Zugang sich wirklich an einer entfernter liegenden Straße befindet, dorthin einen access-node setzt. Es ist ja auch nicht so, dass überall und in allen Ländern die postalische Adresse den Namen der Straße, an der das jeweilige Gebäude steht, enthält; dies aber wird vom obigen Suchalgorithmus anscheinend erwartet. Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Existenzkrise: Wofür Wege?
Markus wrote: Hallo Fabian, wie legt man Relationen über Teile von Wegen? Grafisch-intuitiv: a) alle im geladenen Fenster enthaltenen Realationen werden gelistet b) eine Relation anklicken und alle damit verbundenen Linien werden hervorgehoben c) eine (Teil)Linie anklicken und alle damit verbundenen Relationen werden gelistet d) mit Hinzufügen kann eine markierte (Teil)Linie in eine Relation eingefügt werden e) mit Neu kann für eine markierte Linie eine neue Relation angelegt werden Die Frage war doch wohl so gemeint: Was ist dann in der Relation, wenn nur eine Teillinie gemeint ist? Fabians naheliegender Gedanke war: zwei Knoten mit den Rollen start und end (sowie der Weg). Müsste eigentlich funktionieren, verlangt aber vom Editor viel Mitdenken - zum Beispiel wenn ein Node gelöscht wird, der in irgendeiner derartigen Relation die Rolle end hat. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf ORS
Pascal Neis wrote: Durch die Unscharfe-Suche sollten Schreibfehler im Stadt- oder Straßennamen bis zu einem gewissen Grad keine Auswirkungen bei der Suche verursachen. Wie alle anderen hier, die sich geäußert haben, bin ich sehr angetan von den neuen Features. Ich will das hier deutlich sagen - denn wenn dann bei vielen ein aber kommt, dann kommt das ja gerade davon, dass die Sache so gut ist und man deshalb gerne Kreativität entwickelt und weitere Entwicklungsmöglichkeiten erkennt. Eine grundlegende Frage habe ich zu der Suchfunktion: Erhöht es nicht das Fehlerpotential, wenn Ortsname und Straße prinzipiell ohne Trennungszeichen eingegeben werden müssen (Frankfurt Am Mainufer 13 u.ä.)? Man könnte doch ein fakultatives Trennzeichen verwenden (Frankfurt; Am Mainufer 13), an dem sich die Suchfunktion dann orientieren könnte. (Ich habe hier übrigens ein Semikolon verwendet und kein Komma, da letzteres z.B. in Italien zur Trennung zwischen Hausnummer und Straßenname verwendet wird). Weiterhin werden jetzt auch Hausnummern bei der Suche verwendet (soweit in OSM vorhanden!). (thx Christof) Das heisst: - wird bei einer Suche die Hausnummer im Datenbestand gefunden, wird diese zurück gegeben - wird eine Hausnummer zwischen zwei vorhanden Hausnummern gefunden, wird interpoliert - andernfalls findet die mitgesendete Hausnummer keine Anwendung Viele solche Dienste geben irgendeine Art der Rückmeldung, wenn die genaue Hausnummer nicht gefunden wurde. Wäre das hier nicht auch gut? Immerhin wird z.B. die Adresse Köln Berliner Straße 999 derzeit (die dortigen höheren Hausnummern habe ich erst vorletzte Woche und auch nur vereinzelt gemappt) einige Kilometer entfernt von der richtigen Stelle angezeigt, und da wäre m.E. eine Warnung hilfreich. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank aufspalten
Torsten Leistikow wrote: Ich habe mir die Sache noch mal durch den Kopf gehen lassen, und ich denke, dass diese Sonderstellung der Kuestenlinie letztendlich fuer mich der springende Punkt ist. Eigentlich ist die Kuestenlinie uns vollkommen egal. Was uns fehlt ist die flaechenmaessige Erfassung der Meere und Ozeane. Mal abgesehn von der dafuer notwendigen Arbeit, spricht da eigentlich wirklich was dagegen? Ich könnte mir gewisse ernste Perfomanceprobleme vorstellen, wenn JOSM beim Editieren in Küstennähe eine feinstdifferenzierte gesamte Umrisslinie des afroeurasischen Großkontinents laden will ... Oder habe ich Dich da falsch verstanden? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf ORS
christof.amelun...@sbg.ac.at wrote: Hatto von Hatzfeld schrieb: Man könnte doch ein fakultatives Trennzeichen verwenden (Frankfurt; Am Mainufer 13), an dem sich die Suchfunktion dann orientieren könnte. [...] Trotzdem hilfst du dem Service, wenn du ein Komma als Trennzeichen benutzt! Ich erinnerte mich an eine Suche (vor längerer Zeit), bei der ich erst dann überhaupt etwas fand, als ich das Komma entfernt hatte. - Jetzt kann ich es aber nicht reproduzieren. Vielleicht wurde inzwischen ja etwas geändert. Viele solche Dienste geben irgendeine Art der Rückmeldung, wenn die genaue Hausnummer nicht gefunden wurde. Einen (zugegebenermaßen vielleicht nicht ganz offensichtlichen) Hinweis bekommst du schon in der Liste der gefundenen Adressen. Wird die Hausnumer exakt gefunden, dann steht sie dort drin. Wurde sie interpoliert steht da z.B. 40-48 und wenn gar nichts gefunden wurde, dann steht dort nur die Straße. Vielleicht wäre es doch gut, darauf etwas deutlicher hinzuweisen. Zumindest dann, wenn es überhaupt keine Anhaltspunkte für die Position innerhalb der Straße gibt (was derzeit noch oft der Fall sein dürfte). Was mir aber jetzt noch auffiel: Anscheinend werden Service-Wege bei der Suche nicht berücksichtigt. Das wäre m.E. aber sinnvoll. Ein Beispiel ist die Adresse Melissenweg 32, Köln, die sich am westlichen Ende einer kleinen Zufahrtsstraße befindet. Angezeigt wird aber ein Punkt, der wohl die dem betreffenden Haus nächste Stelle der mit Melissenweg benannten residential-Straße ist. Seltsamerweise wird bei Melissenweg 22, Köln aber die richtige Position angezeigt, obwohl das auch ein Service-Weg ist. Aufgefallen ist mir auch etwas im Fall, dass die addr:street sich vom Namen der nächstliegenden Straße unterscheidet. Da wird der nächste Punkt der namensgleichen Straße und nicht einer auf der nächstliegenden Straße genommen. Das mag manchmal sinnvoll sein; aber zum Beispiel bei Im Weidenbruch 46, Köln wird auf diese Weise eine Stelle beim Tunneleingang der Straße Im Weidenbruch angezeigt, während die richtige Zufahrt am Melissenweg liegen und am Melissenweg 20, Köln vorbeiführen würde. - Zur vereinfachten Demo habe ich hier einmal den Weg von der echten Position des Adress-Nodes zu der mit der Suche ermittelten Position Im Weidenbruch 46, Köln verlinkt: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=7.0278436,50.979942end=7.0278114,50.9803202pref=Shortestlang=de Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf ORS
Pascal Neis wrote: wie vielleicht verschiedene von euch bereits mitbekommen haben gibt es zwei Neuerungen auf OpenRouteService.org (ORS). Was mir noch auffiel: Bei meinen Tests des Fußgänger- und Fahrradroutings verwirrt mich derzeit, dass es (bei der Anzeige mit mapnik) manche blauen Rad- bzw. roten Fußwege gibt, die nicht berücksichtigt werden, während andere durchaus einbezogen werden. Wenn ich richtig gesehen habe, dann liegt das daran, dass highway=path; foot/bicycle=designated beim Routing noch ignoriert werden. Müsste sich das nicht recht leicht ändern lassen? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur API v6
Tobias Wendorff wrote: Dominik Spies schrieb: 7 Nachkommastellen. Ob das jetzt gerundet oder abgeschnitten wird, wenn du mehr übermittelst, kann ich nicht sagen, Probiers aus. Wenn abgeschnitten wird, beträgt der maximale Fehler 14,0 cm. Für OSM sollte es ausreichen :-) Hmm - wenn sich die Tendenz fortsetzt, jeden Pflasterstein oder auch nur jeden Meter abgesenkter Bordsteine zu taggen, weil da ja ein Radfahrer von der Autospur auf den Radweg wechseln könnte, dann fürchte ich, dass bald auch nicht mehr reichen wird ;- SCNR Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Zugangsbeschränkungen
Hallo! Es wurde ja bereits öfters diskutiert; mir ist aber kein eindeutiger Konsens bekannt: Wie soll man Folgendes taggen? 1. Eine Anliegerstraße (d.h. Verboten für Fahrzeuge aller Art mit dem Zusatzschild Anlieger frei), die wegen einer Brücke für Fahrzeuge über 3,5 Tonnen gänzlich gesperrt ist (auch für Anlieger) 2. Eine Wohngebietsstraße mit einem Verbot für Fahrzeuge über 1,5 Tonnen und dem Zusatzschild Anlieger frei. Eine simple Kombination von access=destination und maxweight=... kann es ja nicht sein (zumindest nicht gleichermaßen in beiden Fällen). Anders gefragt: Hebt das access=destination die sonst genannten Restriktionen sämtlich auf? Wenn das so ist, dann wäre access=destination und maxweight=... der zweite Fall und man könnte sich im ersten Fall damit behelfen, im ersten Teil der Straße ein kleines Stück als access=destination und ein zweites Stück als maxweight=1.5 zu taggen. Schön ist das aber nicht ... Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmiersprachenvorliebendiskussion
dgdg wrote: Ich möchte einfach nur einen Node setzen und ihm Tags zuweisen. Dafür mache ich in JOSM folgendes: - Modus Setze Knotenpunkt aktivieren - Knotenpunkt per Mausklick setzen - ESC drücken um die Gummibandlinie loszuwerden Wenn Du die Gummibandlinie unbedingt loswerden willst (was nicht nötig ist!), dann wäre es besser, hier s (=select) zu drücken. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wir ertrinken in Bugs - Aufruf!
Gary G: wrote: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//DEHTMLHEADMETA HTTP-EQUIV=Content-Type CONTENT=text/html; charset=us-asciiTITLEMessage/TITLE/HEAD Mir wäre es lieber, wenn man sich in einer Mailingliste auf HTML-freie Mails beschränken würde ... BODYPHi,/P Pin der Bugs-Statistik steuern wir jede Woche ein neues Hoch an! Siehe hier: A href=http://wiki.openstreetmap.org/wiki/OSB_Reports;http://wiki.openstreetmap.org/wiki/OSB_Reports/A /P PVielleicht gelingt es uns in einer Hauruck-Aktion, mal einen Knick in den Aufwärtstrend zu schlagen? Wenn jeder sich mal sein Gebiet und einige andere Bugs auch vornimmt... Also los!/P Okay; ich habe eben meinen Bereich diesbezüglich bearbeitet. JOSM verfügt über ein OSB-Plugin ! Ist durchaus hilfreich; es wäre aber besser, wenn man auch noch, ähnlich wie im Validator, einzelne Bugs aus der Liste auswählen und dorthin zoomen könnte. Sonst sieht man die Bugs vor lauter Ways und POIs nicht. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] User im Kreis Esslingen
Felix Peters wrote: Seit etwa 3 Monaten bin ich jetzt bei OSM aktiv und versuche seit her die Datenbank in meiner näheren Umgebung weiter zu füllen. Im Kreis sind aber auch noch einige andere User aktiv und ich wüsste gerne mal wer das so ist und wie viele es überhaupt sind. Auf http://www.itoworld.com/static/osmmapper kannst Du - nach Registierung - Dir gute Übersichten über die Aktivitäten in Deinem Gebiet anzeigen lassen. Dann findest Du über Users - [Name] - OSM user page auch zur Möglichkeit, ihnen eine Nachricht zu schicken. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Simon Kokolakis wrote: Man muss ja nicht zwangsläufig seinen echten Namen benutzen, sondern von mir aus auch einen erfundenen Realnamen. Für die Leser ist es nicht wichtig ob hinter dem Namen wirklich die exakte Person steckt oder nicht. Hautsache man ist mit dem Namen immer zu identifizieren. Das ist auch der wichtige Unterschied zwischen Nicknames und Pseudonymen. Wer in einem Realnamen-Umfeld (darauf kommt es an!) nämlich Nicknames nutzt, der signalisiert, dass er sich verstecken will und nicht identifiziert werden möchte. Wer ein Pseudonym verwendet, der ist zwar auch nicht leichter mit seinem Realnamen zu identifizieren, aber er gibt kein entsprechendes Signal. Mit einem Pseudonym hat man sozusagen ein anderes Gesicht, mit einem Nickname eher eine Maske. Letzteres aktiviert naturgemäß Vorbehalte bei Kommunikationspartnern, die keine Maske bzw. keinen Nickname tragen. Nicht das Tragen eines anderen Namens erregt Aggression, sondern die (- wie gesagt - in einem Realnamen-Umfeld so zu verstehende) Botschaft, dass man nicht identifiziert werden und dementsprechend nicht mit seiner ganzen Person zu seinen Äußerungen stehen will. Grüße, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import des Straßennetzes von Straße n.NRW
Sebastian Hierholzer wrote: Das WMS-Layer hat ja ganz markannte Farben, ich hatte die Idee ein Programm/Plugin zu programmieren, welches die Straßenverläufe automatisch nachzeichnet, und eventuell auch noch einen Wizard zur Erweiterung der gefundenen Nodes und Ways. Kann mich ja mal dran versuchen :-). Wäre es dann nicht besser, die Rohdaten zu verwenden? Ein Link wurde hier ja schon genannt. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Betriebssysteme für OSM-Anwender
Ulf Lamping wrote: André Reichelt schrieb: Martin Trautmann schrieb: ... und dass die Shortcuts im Menu angezeigt werden, fehlt bei vielen Win-/Java-Programmen. Zusätzliche Arbeit, die keine wirklichen Vorteile bringt, sparen sich programmierer meist. Da hat z.B. das Vidual Studio einen Vorteil: Hier wird jedem Knopf im Menü die Tastenkombination direkt zugewiesen und dann vollautomatisch angezeigt. Ist ja auch nur im JOSM schon seit Monaten so eingebaut. ... und sehr hilfreich. Das unterstützt den Lernprozess des Anwenders bezüglich der Shortcuts enorm. Einen Dank an die Programmierer! Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import des Straßennetzes von Straße n.NRW
Johann H. Addicks wrote: Und bei der Gelegenheit möchte ich den fleißigen Mappern in NRW auf die Schultern klopfen, man muss schon ziemlich lange suchen, um wenigstens eine Gemeindestraße von diesem Import zu finden, der bislang nicht schon gemapt wurde. Das fiel mir auch auf. Im Hochsauerlandkreis habe ich aber noch eine Reihe von Kreisstraßen und sogar eine Landesstraße gefunden und gleich importiert. :-) Und das schon vorhanden ist, das stimmt wirklich gut mit den amtlichen Daten überein. Mit gewissen Ausnahmen habe ich das auch so vorgefunden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Oberpfalz: Pipeline westlich von Schwandorf?
Hallo! Auf den neuen Luftbildern habe ich etwas Seltsames entdeckt und, eine Vermutung anstellend, als Pipeline getaggt: http://www.openstreetmap.org/browse/way/29054176/ Jemand hatte einen Teil davon schon als road getaggt und ins Straßennetz eingebunden; aber das ist mit Sicherheit keine Straße. Aber was sonst? Hat jemand hierzu irgendwelche Ideen oder Ortskenntnisse? Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach: Hilfe bei Elemente wiederherstellen
Jan Tappenbeck wrote: Moin ! ich habe gerade gesehen, dass bei die südliche Fahrbahn der Autobahn bei Esteponia weg ist - nur noch ein Stumpen. Ich weiß aber, dass dieser da war - kann mir den einer wiederherstellen - ich komme mit Potlatch trotz Beschreibung einfach nicht klar. http://www.openstreetmap.org/?lat=36.51534lon=-4.85819zoom=15layers=B000FTF Ich habe den Verdacht, dass gelöschte Straßen irgendwann endgültig gelöscht werden. Jedenfalls zeigt Potlach auch nach Drücken von u mir dort keine gelöschte Straße an. - Dann hilft nur noch erneutes Malen :-/ Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ensdorf Oberpfalz - Wald gelöscht
Der Wald auf http://www.openstreetmap.org/?lat=49.3703lon=12.0087zoom=13 (zwischen Schwandorf, Schwarzenfeld und Ensdorf) ist anscheinend versehentlich gelöscht worden, wie man im Vergleich mit Mapnik und Osmarender zur Zeit sehen kann. Ich habe ihn jetzt wieder hergestellt. Vielleicht müsste aber Leute, die in letzter Zeit da editiert haben, nachprüfen, ob alles richtig ist; es gab nämlich auch Teilstücke, in die jemand den Wald wohl zerlegt hatte. Auf http://wiki.openstreetmap.org/wiki/DE:Potlatch#R.C3.BCckg.C3.A4ngig-Funktion steht übrigens, wie man solche Löschungen wieder rückgängig macht. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ...LVA-B-Luftbildern - Sinnhaftigkeit von Road
André Reichelt wrote to Garry: Ich sagte ja schon meine Meinung zu road. Und ich will jetzt mal meine dazu sagen: Die Warscheinlichkeit, dass man sich grob verschätzt ist viel geringer als die Warscheinlichkeit, dass sich jemand vor Ort findet, der das korregiert. Ein Weg, der als road getaggt ist, stößt mich mit der Nase darauf, dass hier etwas zu tun ist. Nach meiner Erfahrung werden solche Wege dann auch bald von jemandem, der sich dort auskennt oder der aus diesem Grund vor Ort vorbeischaut, um die fehlenden Daten ergänzt. Hat jemand sich leicht verschätzt (z.B. einen nur für landwirtschaftlichen Verkehr zugelassenen Feldweg für eine Ortsverbindungsstraße, d.h. unclassified, gehalten), dann fällt das nur jemandem auf, der die Straße schon kennt. Also ganz klar: Pro 'highway=road'. Wenn die Klassifizierung dagegen aus dem Luftbild erschlossen wird, dann wäre zusätzlich eine dementsprechende Angabe sinnvoll, z.B. 'source=DOP_LVA_BY_01 only'. Das könnte dann von einem Mapper vor Ort durch 'source=DOP_LVA_BY_01, survey' ersetzt werden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dringende Frage zur Vorgehensweise den LVA-B-Luftbildern
(off topic) André Reichelt wrote: Ich gehe dann einfach davon aus, dass Leute vor Ort das erkennen und dann gegebenenfalls korregieren. [...] Den Mann mit Ortskenntnis brauchst Du so oder so. Wie soll man es denn sonst korregieren. Könntest Du die Schreibweise des Wortes korregieren zu korrigieren korrigieren? Mir tut das weh, so oft stolpere ich in Deinen Mails darüber. SCNR, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: zusätzliche Fahrradwegdefinition en
Karl Eichwalder wrote: Fazit: wenn schilder stehen, immer footway oder cycleway verwenden. Im gelände, wenn es mal keine schilder gibt, ist path ok. Die Unterscheidung zwischen path (unbeschilderter Gewohnheitsweg) einerseits und footway/cycleway scheint mir recht sinnvoll. Dumm ist dabei aber, dass damit noch nicht geklärt ist, wie ein als Fuß- *und* Radweg beschilderter Weg zu kennzeichnen ist. Zur Zeit ist sehr ärgerlich, dass dieser inzwischen auf drei verschiedene Weisen erfasst wird und man beim Betrachten der gerenderten Karten nicht sieht, dass es genau derselbe Wegtyp ist. - Aber vielleicht besteht hier eher bei den Renderern Handlungsbedarf? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: zusätzliche Fahrradwegdefinition en
Bernd Wurst wrote: Ich kenne nur die alte Definition das größte regulär erlaubte Verkehrsmittel gibt die Kategorie vor Hm - das war mir bisher noch nicht bewusst, ist aber, wenn ich an gewöhnliche, für Autos gedachte Straßen denke, logisch. und damit highway=cycleway / foot=yes Das ist laut http://wiki.openstreetmap.org/wiki/DE:Road_Signs eine Fahrradstraße ... oder alternativ für die die's Umständlich wollen die path-Variante: highway=path / foot=designated / bicycle=designated. Weitere Formen gäbe es noch z.B. bei Fußwegen (die als Fußweg gedacht sind) bei denen zusätzlich Radfahren erlaubt ist (highway=footway / bicycle=yes). Aber das ist ja was anderes als kombinierte Rad-/Fußwege. Und geklärt war es schon, bis irgendwann jemand auf die Idee kam, ein unspezifizierter path könnte mit ner Latte Zusatz-Tags auch dasselbe aussagen wie das was wir vorher schon hatten. :( Ja, so steht's auf http://wiki.openstreetmap.org/wiki/Approved_features/Path Was da fehlt ist die Angabe, wie man die beiden Arten, also einen kombinierten Rad-/Fußweg und einen Fußweg, der per Zusatzzeichen auch für Radfahrer erlaubt ist, bei path unterscheidet. Seufz. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben // Vorgehensweise?
Garry wrote: Ulf Möller schrieb: das auch so getaggt werden. Wenn Radfahren in Schrittgeschwindigkeit erlaubt ist, müsste da eben eine Geschwindigkeitsbeschränkung getaggt werden. Glaube nicht dass sich da wirklich jemand dafür interessiert was da getaggt ist - der verantwortungsbewusste Radfahrer fährt dort per Augenschein angepasst, die anderen kümmern sich eh nicht darum. Das mag sein; aber für ein Fahrradrouting ist es schon relevant, dass solche Daten erfasst werden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue OSMer
Markus wrote: Je häufiger OSM in der Presse erscheint, desto mehr Menschen werden auf uns aufmerksam und haben vielleicht Lust mitzuarbeiten. Früher waren die Neuen eigentlich meist schon Alte Hasen. Also Menschen aus der Linux-Szene, aus der OpenSource-Szene, Programmierer, Datenbankspezialisten, aber auch Geometer, Geografen, Kartografen, Geocacher, etc. Das ist auch kein Wunder; schließlich verlangen grafische Anwendungen, was die Bedienung betrifft, dem Nutzer schon einiges mehr ab als beispielsweise Textverarbeitungsprogramme. Heute kommen zunehmend Menschen zu uns, die ein Navi im Auto haben, einen ALDI-Vista-PC besitzen und darauf Briefe schreiben, chatten und Fotos anschauen können. (ok, manchmal auch ein bisschen mehr) Wenn sie nicht ein bisschen mehr können, dann ist die Schwelle zu OSM aber sehr hoch, und zu Software wie Potlatch und JOSM fast unüberwindlich. Das sieht man schon daran, dass auch manche alten Hasen ihre Schwierigkeiten haben, in Potlatch oder JOSM einzusteigen, wie es hier ja schon geäußert wurde. Für diese Personengruppe braucht OSM einen eigenen Kanal. Den Klickibunti-Nutzern, die noch nie ein Programm installiert, ein 'Add-In' konfiguriert, Formate konvertiert haben, die nicht wissen, wozu man die rechte Maustaste verwenden kann, Shift- (oder Umschalt-) bzw. Ctrl- (oder Strg-)Klicks nicht kennen, wird eine noch so gute Anleitung schwerlich helfen. Das ist ein bisschen so, als wollte man das Autofahren jemandem ohne Fahrstunden mit Hilfe einer guten Beschreibung beibringen. Die Hürde liegt also m.E. nicht so sehr in der Gebrauchsanweisung von Potlatch und JOSM (auch wenn deren Auffindbarkeit suboptimal ist), sondern in der Anfängerfreundlichkeit dieser Programme selbst. Sie sind eher auf ein effizientes Eingeben getrimmt als darauf, den Nutzer zu den jeweils nächsten nötigen Schritten bzw. Möglichkeiten zu führen. Vielleicht müsste man spezielle Versionen (oder Ergänzungen) zu den vorhandenen Editoren machen, die den Nutzer didaktisch, per Übung zur Bedienung führen. Oder man macht andere, wirklich Klickibunti-taugliche Editoren, die dann aber wohl kaum alle Funktionen hätten. Ich könnte mir - jetzt mal herumgesponnen - vorstellen, dass ein einfacher Editor das Setzen von POIs und das Vergeben von Namen erlaubt, außerdem das Setzen von FIXME-Hinweisen, aber nicht die (schwierigere) Eingaben von Linien. Dann könnte auch jemand, der sonst nur Texte schreibt, leicht bei OSM mitarbeiten und z.B. die durch Luftbildabzeichnen namenlosen Straßen mit den nötigen Angaben versehen. In meinem Einwand gegen eine redundante Pflege hatte ich dagegen mehr die Zielgruppe im Auge, die schon etwas mehr Fähigkeiten hat, aber jetzt vor allem aus Interesse an einer kartographisch guten Wiedergabe ihrer Heimat Oberpfalz zu OSM findet. Für die reicht m.E. eine Übersichtsseite mit Links. Die Seite http://wiki.openstreetmap.org/wiki/DE:Potlatch scheint mir z.B. recht gut zu sein, müsste dann aber, wo es um das Abzeichnen vom Hintergrund geht, ergänzt werden. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue OSMer
John07 wrote: Markus schrieb: Heute kommen zunehmend Menschen zu uns, die ein Navi im Auto haben, einen ALDI-Vista-PC besitzen und darauf Briefe schreiben, chatten und Fotos anschauen können. (ok, manchmal auch ein bisschen mehr) [...] Diese Gruppe will nicht verstehen, sondern haben: Klick und es läuft. Die sollen dann bitte Openstreetbugs nutzen, genau dafür ist es da. OSM ist einfach komplex, das kann man gar nicht so einfach machen, dass es für deine Zielgruppe klappt. Tendenziell sehe ich das, wie in der vorigen Mail geschrieben, auch so. Wenn nun aber jemand seine Ortskenntnis nutzen will - und dafür sehe ich beim Projekt Oberpfalz gute Chancen -, um ohne die Komplexität von JOSM und Potlatch Informationen an schon gezeichnete Objekte anzupappen, also z.B. Straßen zu benennen, dann ist mir der Kanal von OpenStreetBugs zu OSM zu dünn. Es muss ja immer jemand umständlich nacharbeiten, was da an Bugs eingegeben wurde. Ginge das nicht besser, z.B. mit einem speziellen Editor für solche User? Oder habe ich beim Weg, wie Daten von OpenStreetBugs in OSM einfließen, etwas übersehen? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
