Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Felix Hartmann wrote: >Sprich für die User wird es großteils (Ausnahme Garmin - weil >hier ja das Format geknackt ist) - keine kostenlosen Karten geben. Dieses Argument höre ich hier nicht zum ersten Mal. Die Wirtschaft funktioniert aber etwas anders: Nehmen wir mal an, es gäbe für Garmins (und nur für Garmins) kostenlose Karten, die auch funktional den derzeit verkauften Navteq-Karten fast gleichwertig wären. Welch Folgen hätte das? Für Garmin wäre es günstiger selbst diese OSM-Karten statt der (auch im Einkauf) teureren Navteq-Karten auf ihre Navigationsprogramme zu optimieren (TTS-Ausgaben, Fahrzeitschätzungen etc.). Der Preis für diese Karten würde fallen müssen um mit kostenlosen Karten konkurrieren zu können. Mit billigen Kartenupdates hätte nun aber Garmin ein Verkaufsargument gegenüber z.B. TomTom und Navigon, die darauf selbst nachziehen müssten. Auch deren User hätten einen Nutzen. Was OSM also erreichen kann, ist den kommerziellen Wert von Geoinformationen zu senken. Und das auch noch "je freier die Lizenz - umso besser". Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] name:de oder old_name in ehemals deutschen Gebieten?
Sven Geggus wrote: >Ich denke gegen name:de kann niemand was sagen der wirklich darüber >nachgedacht hat. ... solange name:de eine "deutsche Form" des landessprachlichen Namen ist. name:de ist IMHO vorgesehen für lokalisierte Nutzungen der OSM-Daten. Historische Daten haben dort z.B. in Straßennamen nichts zu suchen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NACK Gemeindegrenzen Baden-Württemberg für OpenStreetMap
Christian Schmitt wrote: >Wir haben irgendwann mal beschlossen aus dem Steuertopf amtliche >Kartenwerke erstellen zu lassen. Für deren Benutzung werden wir >paradoxerweise abermals zur Kasse gebeten. Daran ist doch nichts paradox. Der Teil, der von den wenigen Nutzern bezahlt wird, muss eben gerade nicht aus dem Steuertopf genommen werden. Die 99% Nichtnutzer sind's zufrieden. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Guenther Meyer wrote:
>ich finde, es sollte einfach zusammengepackt werden, was sinngemaess
>zusammengehoert.
Aber das kann man an einem Wort ("...schule") sicherlich nicht. Haupt-,
Baum- und Delfin-Schulen haben genau *nichts* miteinander zu tun.
Norbert
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Guenther Meyer wrote: >bei den adressen hat's komischerweise funktioniert: >da haben sich ein paar leute zusammengesetzt und ein klares schema >ausgearbeitet, und es wird benutzt. >beim oepnv-schema ist es glaub ich aehnlich... In diesen Fällen haben die "Macher" auch OSM verstanden und aufgepasst, dass nicht an der Bedeutung von bestehenden Tags herumgeändert wurde. >warum geht sowas bei POIs nicht? Es geht sicherlich. Aber nicht indem man die Bedeutung eines Tags (hier im Beispiel "shool") ändert und damit tausende von vorhandenen POIs "entwertet". Norbert PS: Und *nein*, dass man auf die alte Bedeutung schließen kann indem ein "Nebentag" ausgewertet wird, ist keine Lösung. Es zeigt nur auf, dass genau so eine Bedeutungsveränderung stattfinden soll. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Porto Velho und Palmas
Sven Geggus wrote: >> Mir scheint, dass dort alles (Rinnsale, Bäche, Flüsse, Ströme) >> in einem Topf zusammengemischt wurde. > >Siehe anderes Posting von mir. Wir brauchen endlich definierbare >Flußbreiten in Mapnik. In der mapnik-Karte tritt das "Problem" doch gar nicht so sehr auf. In den Mapnik-Styles werden "kleine" Gewässer doch nur in Maßstäben dargestellt, in denen sie auch sinnvoll sind. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flußbreiten (was: Zwischen Porto V elho und Palmas)
Sven Geggus wrote: >> Ich finde, dass die waterway Linientypen in z12-captionless nicht mehr >> dargestellt werden sollten. Flüsse, die in z0-z11 zu sehen sein müssen, >> sind so groß, dass sie auch als Flächen (mit riverbank) erfasst sind (bzw. >> bald sein werden). > >Das Problem ist ein Vollständig anderes! Ein karthograph hat mir >erklärt, dass Flüsse auf karten generell in ihrer wirklichen Breite >dargestellt werden und im gegensatz zu Straßen nicht überbreit. > >Das habe ich in osmarender realisiert, sodass ein Fluß mit >Breitenangabe (nur falls erfasst natürlich) im richtigen Maßstab >gezeichnet wird. Dann sind aber die Breiten, die genutzt werden wenn keine Angabe gemacht wurden, in z12-captionless *viel* zu groß. Immerhin ist lt. tag-Beschreibung im Wiki ein waterway=stream "überspringbar" und ein waterway=river schmaler als 12m. Drain dürfte normalerweise vergleichbar zu river sein. Norbert PS: Der Graben hinter meinem Haus wird übrigens von "professionellen" Kartographen nur in Detailkarten eingezeichnet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Porto Velho und Palmas
Martin Czarkowski wrote: >Es scheinen Flüsse und Bäche zu sein, aber so viele auf einem Fleck? Ab Zoom 12 sieht das doch ganz ok und richtig aus. >Wenn das überall in dieser Dichte wäre, würde das die Karte total >verunstalten. Tut's ja schon in Teilen der US und GB. Ich finde, dass die waterway Linientypen in z12-captionless nicht mehr dargestellt werden sollten. Flüsse, die in z0-z11 zu sehen sein müssen, sind so groß, dass sie auch als Flächen (mit riverbank) erfasst sind (bzw. bald sein werden). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann wrote: >Würde er >bedingungslos alle Wege mit "bicycle=*" ins Routing aufnehmen, würden >einige Leute sehr nass werden. Vielleicht sollte er eben zusätzlich zum Haupttag "bicyle=yes" auch die beschreibenden Nebentags z.B. "highway=" auswerten (schon allein um eine schöne Farbe für den Weg auszusuchen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: >So wie vorgestern highway=gate zu barrier=gate wurde, vorvorgestern claas=* >zu highway=*. Solange dokumentiert und bekannt kann sich jeder wie bei jeder >anderen Änderung darauf einstellen. Das Problem liegt jetzt wo? Darin, dass highway=gate nicht plötzlich eine zusätzliche andere Bedeutung bekommen hat - du aber für "bicycle=yes" zusätzlich zum bisherigen "hier kann man Fahrrad fahren" heute auch "hier sind Infos für Fahrradfahrer", morgen "hier kann man Fahrräder kaufen", übermorgen "an diesem Kirchturm hängt ein Fahrrad (gibt's wirklich)" usw einführen willst. >> - sinnloses Gehopse! > >Nö ganze normale Enetwicklung in einem offenem System. Wenn du kein Gehopse >willst dann musst du von offen auf verabschiedete Standarts umschwenken. Lerne Lesen. *sinnloses* Gehopse. offen<>hohl Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Haupt-Tags (was: guidepost)
Tobias Knerr wrote: >... informell ... sinnvoll ... oft ... erfolgt durchaus auch ... die paar >Ausnahmen ... m.E. ... die meisten Tags ... Konzept? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: >Nebulös ist da garnichts. In Verbindung mit Guidepost kein access. Ganz >einfach. Ich glaub' jetzt hast du's ;-) Also: Ab heute müssen alle Auswertungen umgestellt werden, damit sie (wenn gleichzeitig Guidepost vorhanden ist) nicht mehr von der Bedeutung "access" ausgehen. Ab morgen müssen ... Ab übermorgen müssen ... - sinnloses Gehopse! Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: >Nein denn er will ja garnicht erst von bicycle=yes weg sondern alles andere >soll sich bitte eine entsprechend neue Definition suchen. Er klebt an seiner >Definition, Begründung weil etabliert. *Warum* sollte er denn auch von bicycle=yes weg? Wenn es mal einen Grund gäbe, dann wäre es aber möglich. Natürlich soll sich alles *andere* einen *anderen* Tag suchen. Das verhindert viel sinnloses Gehopse bei der Datenauswertung. >> Wenn du jetzt aber "bicycle=yes" mit anderer Bedeutung nutzen willst, dann >> ist diese Möglichkeit verbaut. > >Eine Möglichkeit die doch keiner hier in betracht zieht. Wann soll die >kommen? Wie geschrieben: "bei Bedarf". Der existiert aber nicht wirklich. >> Wer ein "altes" key/value-Paar mit einer neuen Bedeutung versehen will, >> der >> verwässert die in der DB gespeicherten Informationen. Natürlich gibts da >> "Gegenwind" von denen, deren Arbeit da teilentwertet werden würde. > >Da wird doch nichts verwässert weil beide Tags zusammen einen anderen >dokumentierten Kontext ergeben. Deine Forderung an alle Datenauswerter jetzt und zukünftig einen nebulösen "Kontext" auszuwerten statt eine eindeutige Bedeutung vorzufinden, ist keine Verwässerung? >Ein bicycle=yes kann auf einem Guidepost >kein access sein. Ergo kannst du Guidepost bei einer Routinganwendung guten >gewissens ignorieren. > >> (Und komm' nicht mit "abhängig vom Haupttag" - was soll das sein?) > >Schon tausende male geschrieben. Und schon genausooft mit "Es gibt bei OSM kein Konzept 'Haupttag'. Dafür wäre es nötig technisch durchzusetzen, dass jedes Element einen und genau einen dieser Tags bekäme. Dem ist nicht so." beantwortet. Gruß, Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann wrote: >Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten >benutzt wird, während ein Untertag nur in Kombination mit anderen Tags >anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl >etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist. >"highway=*" ist ein Haupttag. "tourism=*" eines. "information=guidepost" >ist keines und "bicycle=*" sicherlich auch nicht. Und du schreibst also vor, das je way oder node nur genau einer dieser "Haupttags" genutzt werden darf? Ich nehme an, du überarbeitest jetzt auch alle Knoten, an denen derzeit z.B. amenity *und* shop vorhanden sind. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: >Kommt drauf an was hinten rauskommt. Ein generelles mauern wegen ist so >bringt aber auch nicht weiter. Ulf "mauert" doch nicht. Er hat - wie auch andere - versucht dir klarzumachen, wo das Problem liegt. Das derzeitige "bicycle=yes" kann (noch!) bei echtem Bedarf einmal zu "access:bicycle=yes" o.ä. gewandelt werden, denn für genau diesen Fall ist es definiert. Wenn du jetzt aber "bicycle=yes" mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Wer ein "altes" key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da "Gegenwind" von denen, deren Arbeit da teilentwertet werden würde. Norbert (Und komm' nicht mit "abhängig vom Haupttag" - was soll das sein?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was bedeutet Changesets in Bearbeitung?
Tirkon wrote: >Danke für die Antwort. Allerdings habe ich den Speichermodus von >Potlatch benutzt und dennoch hatte die Änderung den Status "in >Bearbeitung". Auch im Speichermodus schließt Potlatch das changeset nicht bei jedem "save" (nicht einmal, wenn du Potlatch beendest). Wenn du wert auf das Beenden des changesets legst, dann kannst du es per"Advanced/Close changeset" (links unten) manuell machen. Für das Speichern der Daten in der Datenbank macht das aber sowieso keinen Unterschied. Ein changeset ist keine Datenbanktransaktion! Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höherwertige Straßen in Orten - cons truction
Garry wrote: >... eine unglückliche Krücke die den üblichen tagging Gepflogenheiten >wiederspricht einen Grundtyp >anzugeben und in weiteren Tags den Zustand und die zulässigen >Nutzungsarten zu beschreiben. ... eine glückliche Krücke, die den üblichen tagging Gepflogenheiten entspricht, das als "Grundtyp" zu erfassen, was wirklich existiert - und nicht was daraus einmal werden soll. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Martin Koppenhoefer wrote: >wenn man sie als solche identifiziert, kann man sie ja verschieben. Wer kann das? Mit welchen Geräten? Genau das sind doch meine Fragen. Die "OSM-Community" kann es jedenfalls nicht. > Mein Garmin mit OSM hat >uns sauber auf der richtigen Seite angezeigt :) Heißt dein Smiley jetzt, dass du selbst weißt, dass das absolut nichts über die Genauigkeit der Daten aussagt? Mein Garmin mit OSM-Karte hat mein Auto auch schon auf parallel verlaufende Radwege geraten. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Martin Koppenhoefer wrote: >mit ein bisschen Übung (und evtl. Unterstützung durch den Editor z.B. >durch ein eingeblendetes Raster zum Abschätzen des Maßstabs) wird man >allerdings deutlich höhere Genauigkeiten als +/-5 m hinbekommen. Damit >würdest Du ja implizieren, dass man eine Straße die z.B. real 8 m >breit ist, evtl. in OSM mit 3 oder 13 m Breite zeichnen würde. Das ist >aber Quatsch. Man würde versuchen, sie ungefähr mit 8 m Breite zu >zeichnen, real dann aber vielleicht auch nur 7,20 m oder 8,50 m >zeichnen. Damit kann man aber gut leben. Du hast mein Beispiel nicht gelesen/verstanden: |Eine Erfassung |"hier ist die durchgehende Fahrbahn, hier die Abbiegespur" ist bei |> Genauigkeiten von +/- 5m beispielsweise eine Nullinfo. Mit der Information "hier ist /meine/ Richtungsfahrbahn" kann man schlecht leben, wenn dort in Wirklichkeit der Gegenverkehr fließt. Warum sollen solche Falschinformationen in OSM? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Martin Koppenhoefer wrote: >Am 15. Juli 2009 19:11 schrieb Norbert Hoffmann : >> >> Die Genauigkeit der Datenerhebung. Die "Strippe" deutet wenigstens an, dass >> es sich nur um einen ungefähren Verlauf handelt (auf einer Karte o.ä. kommt >> es ja auch nicht so drauf an). Eine Erfassung als Fläche täuscht eine >> Genauigkeit vor, die mit Hobbymitteln derzeit wohl nicht zu erreichen ist. > >das ist m.E. ein Nullargument, da es für alle Flächen und sowieso für >alle Dinge zutrifft, die wir eingeben. Der Unterschied liegt darin, dass z.B. "landuse" aber auch Gebäudegrundflächen eine zusätzliche (ungenaue) Information beschreiben. Flächig erfasste Straßen täuschen diese Mehrinfo nur vor. Eine Erfassung "hier ist die durchgehende Fahrbahn, hier die Abbiegespur" ist bei Genauigkeiten von +/- 5m beispielsweise eine Nullinfo. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Tobias Wendorff wrote: >Eine Frage daher: Was hält uns daher eigentlich ab, die Straße als >Fläche einzuzeichnen und zusätzlich eine Strippe drüberzulegen, bis >die Anwendungen auch Flächen als Straße interpretieren können? Die Genauigkeit der Datenerhebung. Die "Strippe" deutet wenigstens an, dass es sich nur um einen ungefähren Verlauf handelt (auf einer Karte o.ä. kommt es ja auch nicht so drauf an). Eine Erfassung als Fläche täuscht eine Genauigkeit vor, die mit Hobbymitteln derzeit wohl nicht zu erreichen ist. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway in osmarender
Heiko Jacobs wrote: >Wenn ich mir das gerade so druchlese, werde ich auch nicht so ganz >schlau draus, welche Stellschraube ab 11 zu drehen ist, sprich in >welcher Datei was zu ändern ist. Ich verstehe das so, dass captionless-z12 das einzige ist, was für dich noch anzupassen wäre. Die Tiles für die lowzoom-Stufen bastelt daraus der Serverprozess sobald ein z12 geändert wurde. Damit diese Tiles nicht zu überfrachtet werden, ist captionless-z12 ja auch etwas vereinfacht: z.B. sind Straßen breiter und auf die flächigen Bestandteile ist ganz verzichtet worden. Das solltest du wohl für deine (IMHO optisch ansprechenden) Änderungen so weiterführen. >Im SVN sind jedenfalls Dateien osm-map-features-z*.xml für 6 bis 17 >Und an 12 bis 17 habe ich bisher erfolgreich gebastelt. Hätte vermutet, >dass ich an den entsprechenden 6 bis 11 weiter machen müsste... Die werden derzeit wohl nicht benutzt. >Allerdings liegt auch ein captionless-z12.xml und caption-z*.xml >für 0 bis 11 drin ... Die Captions sind ja vor Kurzem neu gerendert worden, da ist wohl nichts weiter zu tun. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway in osmarender
Stephan Wolff wrote: >Und die Übertragung der Regeln auf die Lowzoom-Karten steht auch noch aus. Genauer wohl: die Übertragung auf z12 captionless. Der Rest ergibt sich dann doch von alleine. Oder habe ich das "stitching" von z11-z6 falsch verstanden? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway in osmarender (16-17)
Heiko Jacobs wrote: >Nachdem ich mich in einigen Großstädten endlich selbst vergewissern >konnte, dass z17 und z16 zu keinem groben Unsinn führen und >halbwegs brauchbar sind, nun, eigentlich sogar viel schöner >aussehen, kann ich es ja bei Gelegenheit fortführen das System. In z16 könnten IMHO die railways etwas schmaler sein. Nebeneinander liegende Gleise überlappen sich bei der jetzigen Breite bereits meistens. Außerdem benutzt du im Moment wohl die Farben "schwarz" und "durchsichtig". Wenn 2 Gleise dicht zusammen sind, aber die schwarz/weiß-Grenzen versetzt sind, führt das zu einer durchgehenden dicken schwarzen Linie. Evtl. doch das Innere in weiß füllen? Dann setzt sich die zuletzt gemalte Linie durch. Norbert "freut sich schon auf die Änderungen der nächsten Level" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing - Separater Radweg und andere Probleme
Martin Koppenhoefer wrote: >Am 26. Mai 2009 09:24 schrieb Mario Salvini : >> weil du z.B. theoretisch bei jeder Bordsteinkante dann einen "Link-Way" >> zwischen "Straße" und "Radweg" machen müsstest. > >dieses Problem ist allerdings grundsätzlich ungelöst und existiert >auch an anderer Stelle (z.B. Autobahnabfahrten). Dort ist das aber kein Problem, solange Autobahn und Ausfädelspur gemeinsam als *ein* way gemapped werden und die Trennung da erfolgt, wo kein Wechsel mehr möglich ist. Ich plädiere für das gleiche Vorgehen (= eigenständiger cycleway nur da, wo kein Übergang vom Radweg auf die Straße möglich ist). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Heiko Jacobs wrote: >Modifizierungen für tracks z12-z17 und andere schmale Wege z12-z14 >sind hochgeladen. Jetzt liegt das Schicksal in der Hand der >Style-Updates der clients, wann und wo man was sieht... Kann da beim Hochladen etwas schief gegangen sein? Mir ist gerade aufgefallen, dass einige Clients jetzt z17 scheinbar mit den Styles von z16 rendern (nur entspechend größer: http://www.informationfreeway.org/?lat=54.316772877520904&lon=10.138690702138852&zoom=17&layers=BF000F Die Nordhälfte ist ok, im Süden siehts falsch aus. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege
Falk Zscheile wrote: >Besser finde ich Radwege als eigenen way einzuzeichnen, wenn er >baulich getrennt ist. Für nicht baulich getrennte Radwege bietet sich >cycleway=left, cycleway=right, cycleway=both[1] an. Dann verliert man aber die Möglichkeit zwischen cycleway=track und cycleway=lane zu unterscheiden. Es gibt aber auch den Vorschlag ":right"/":left" als suffix zum key zu benutzen: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left . Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Nop wrote: >Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du >mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur >einfache Vererbung haben willst - und keine definierte Regel, wie man >das unterscheiden könnte und auch keine Möglchkeit ein "die beiden oder >auch eine andere"-Ref zu erzeugen. Nehmen wir noch eine neue, unbekannte >Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way >weiteren Relationen zuordnen), und das Chaos ist komplett. Relativiert sich dieses "Problem" nicht dadurch, dass es doch eigentlich nur genau einen Relationstyp (route=road) gibt, der genau dafür geschaffen wurde vererbbare Eigenschaften zusammenzufassen. Die anderen Relationen (z.b. bus) definieren doch andere Objekte, die den Weg nur nutzen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Foot-Access auf cycleway? (Routing (Re: Hilfe, meine Stadt hat Flecken))
Bernd Wurst wrote: >Einen faktischen Unterschied zwischen kombiniertem Fuß-/Radweg und Radweg mit >"Fußgänger frei" kann ich verkehrsrechtlich als Laie irgendwie nicht erkennen. >Den kann man aber so oder so nicht ausdrücken. Nur wenn man (wie du) darauf besteht, beides als cycleway/foot=yes zu taggen. Alle anderen können das sehr wohl. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße.
Mario Salvini begriff: >und wäre sie nicht als Radstraße ausgeschildert wäre es eine normale >Wohnstraße ohne Linien und um die 5m Fahrbahnbreite. So sieht es wohl bei den meisten (allen?) Fahrrad*straßen* aus. Und für "Beschilderung" gibt es nun mal andere als den highway-Tag. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße.
Mario Salvini schrieb, es sei >im OSM-Universum eine Fahrradstraße am besten mit highway=cycleway >motor_vehicle=destination foot=yes abgebildet. Für die Kieler Fahrradststraßen ist das sicherlich nicht "am besten". Die "destination"-Einschränkung für KFZ wäre falsch, und außerdem besitzen hier auch die Fahrradstraßen noch getrennte Fußwege. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Garry wrote: >Sobald hier der Wunsch aufkommt etwas für die Router im Taggingschema zu >optimieren kommt gleich >immer der Einwand "wir taggen nicht für den Router" und "für Router >benötigt man sowieso eine Vorverarbeitung". Du "wünschst also etwas für Router zu optimieren"? Sorry, das ist doch nun wirklich Unsinn. Router benötigen für ihre Aufgaben nun wirklich keine nicht vorhandenen Wege. Du versuchst nur das Tagging für *deine* Belange zu optimieren. Und die Probleme hast du nur deshalb, weil du unbedingt mit dem Schraubendreher einen Nagel einhauen willst (= eine *von anderen* für Routing auf vorhandenen Straßen entwickelte Navi-Karte als Notizzettel für deine Erfassung von Baustellen und Planungen benutzen willst). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Garry wrote: >> Genauso ist es in OSM jetzt schon. >> Osmarender und Mapnik stellen in bau befindliche Straszen dar, >> so sie highway=construction construction=... getaggt werden. >> >... mittels eines doch recht umstrittenen Verfahrens durch Missbrauch >einer Highway-Kategorie. Derjenige, der eine Kategorie "missbraucht", bist doch du. Ein "highway=primary" war bisher (und wird immer noch genau so verstanden) eine existierende, benutzbare Straße mit impliziten Eigenschaften (maxspeed, access etc). Diese werden auch von den die Daten auswertenden Anwendungen für Karten und Routen z.B. so genutzt. Du meinst jetzt durch ein neues tag alle diese Eigenschaften außer Kraft setzen zu müssen und verlangst von allen diesen Geisterfahrern sich dir anpassen zu müssen. Du verstehst den Gegenwind? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks durch Felder
André Reichelt wrote:
>Gibt es Argumente dagegen?
Die jetzigen Lowzooms zeigen den Mappern doch recht gut, wie die "Erfassung
der Welt" vorankommt. Außerdem erkennt man einige Renderfehler, die bei der
Mapnik-Methode ("jedes Zoomlevel wird seperat gerendert") erst in Zoom 12
auffallen. Wer würde sich schon z.B. ganz Europa in Zoom 12 ansehen wollen?
In Zoom 5 sieht man derzeit z.B. noch, dass irgendwie in einem Streifen
mitten durch Frankreich in N-S-Richtung die Z12-Captionless-Tiles leer
gewesen sein müssen - inzwischen größtenteils nachgerendert. Ab etwa Zoom 7
sieht man einige schwarze Klötze. Auch hier ist beim Rendern der hohen
Zoomstufen was falsch gelaufen.
Mir gefällt es so, wie es ist: Mapnik-Layer für die bis auf die erkennbaren
Details vereinfachte Karte in allen Zoomstufen und Osmarender-Layer als
Hilfsmittel für die Erfassung (viele Informationen aber optisch etwas
überladen).
Norbert
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung
Johann H. Addicks wrote: >Wie funktioniert es, Namen von Ortschaften/Gemeinden >a) "für die geonames-Suche vollständig" zu schreiben >b) auf der Karte aber keine Bandwürme beschriftet zu bekommen? SO sollte es gehen: Du änderst im key "name" und löschst "name," aus dem key "openGeoDB:auto_update". Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
Frederik Ramm wrote: >> Das wurde doch gemacht! >> Bei mir hier ist "population" vom GeoNames-Import eingetragen. >> Incl. "openGeoDB:auto_update=population". :) > >Hm, ich hatte den Eindruck, dass das nur sporadisch vorhanden waere, >das war auch mit Anlass zu meiner Nachfrage nach dem Stand der Dinge. >Kann es sein, dass all jene Staedte, die schon vor dem Import einen >eigenen Node hatten, keine Bevoelkerungszahl verpasst bekommen haben? Ich schätze, dass viele Mapper den (wegen der langen Namen doppelten) "OpenGeoDB-Ort" gelöscht haben. Bei mir in der Gegend habe ich mir die Mühe gemacht, den "alten" Ort zu löschen (sofern ohne zusätzliche Infos), den GeoDB-Ort zu verschieben und "name" aus auto_update rauszunehmen. Sowas in der Art erwarte ich von einer zukünftigen Datenübernahme automagisch. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry wrote: >Durch die Nichtdarstellung schliesst Du eine ganze Gruppe an Anwendern >(die die mit der jeweiligen >Baustelle zu tun haben) die besonders Interessante Daten für OSM zur >Verfügung stellen könnten. Niemand hindert dich oder andere daran, für speziell an Baustellen Interessierte, auch spezielle Karten (...) herzustellen. Die Daten ja sind in beiden Fällen vorhanden. Nur nach dem Vorschlag von Tordanik müssten *alle* Altanwendungen geändert werden, um nicht plötzlich Alt- und Plan-Daten als Ist-Zustand misszuverstehen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik wrote: >>> Im Bau befindliches Atomkraftwerk: >>> power=generator >>> power_source=nuclear >>> status=construction >> >Hast du einen speziellen Gegenvorschlag? Zu jedem Objekttyp wäre doch eine Erfasung analog zu "highway" und "rail" möglich: power=construction construction=generator power-source=nuclear Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry wrote: >Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche >Strecken vielen >gängingen "Produktiv"-Andwendungen (Garmin, NaviPowm)dargestellt. Das ist doch auch gut so. Ich möchte, dass mein Navi mich über Straßen routet und nicht über Baustellen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik wrote: >Für „abandoned“ kommt dein Einwand eher zum Tragen. Ich sehe aber nicht >wirklich einen Unterschied in der Darstellung der Realität, ob ich eine >ehemalige Straßenbahnschine als „abandoned railway“ beschreibe oder als >einen „tram-railway, der im abandoned-Status ist“. Für mich gibt es im 2. Fall nichts mehr, das einen Status haben könnte. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik wrote: >Beispiele: > >Nicht mehr genutzte Schienen: >railway=[Railway-Typ] >status=disused >(Man beachte, dass – im Gegensatz zu railway=disused – die Art der >Schiene wie gewohnt angegeben werden kann.) Man beachte aber auch, dass an einer mit railway= beschriebenen Stelle, nach deinem Vorschlag gar keine Schiene mehr liegt. Die derzeit gültige "Vorschrift" stellt die Realität besser dar. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations, Site und Gewerbeparks
Thomas Hieber schrieb (über Relationenunterstützung durch Render-SW): >type=multipolygon --> Wird genutzt um Löcher in Flächen zu erstellen >(z.B. Lichtungen im Wald) Eigentlich ist multipolygon so definiert worden, dass die Renderer es gar nicht verstehen müssen (Uhrzeigersinn / gegen den Uhrzeiger / tags nicht beim Polygon, sondern an beiden ways). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zu viel Traffic!
Jacques Nietsch wrote: >Eine andere ernst gemeinte Frage an die 'alten Haasen' hier: warum >gibt es zu diesem Thema eigentlich keine Gruppe im Usenet? Oder gibt >sie es doch? Die Mailingliste selbst wird als 'gmane.comp.gis.openstreetmap.region.de' bei gmane (news.gmane.org) angeboten. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Multipolygon und Landuse
Martin Simon wrote: >Falls es kein grundlegendes logisches Problem gibt: lasst uns bitte >nicht wieder um die unzulänglichkeiten eines Renderers herum mappen... Genau das macht aber die derzeitige Multipoligon-Relation. Ein See (mit Loch=Insel) wird logisch erst durch die Relation beschrieben. "natural=water" muss also Attribut der Relation sein. Der äußere way benötigt _kein_ Attribut (er alleine bestimmt ja auch nichts) und der innere way könnte bei Bedarf z.B. mit "natural=wood" getagged werden. Ein zusätzlicher way mit identischen nodes ist eigentlich unnötig. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ToDo Kenzeichnung
Guenther Meyer wrote: >Am Donnerstag 12 Juni 2008 schrieb Karl Eichwalder: >> Nimm einfach einen "gültigen" highway type (jetzt wohl am besten "road") >naja, wenn ich aber nicht weiss, welcher strassentyp es ist, macht es noch >weniger sinn, irgendeinen anzugeben. Deshalb: "road". >wenn ich's nach deiner methode mache, dann sieht jemand zwar, dass da noch was >gefixt werden muss, Ja. >aber nicht was. da bereits ein strassentyp angegeben ist, Nein. >wird der dann schon stimmen, und irgendwas anderes fehlt noch... >das waere zumindest meine erste logik... Wer die Bedeutung des highway-typs "road" nicht kennt, sollte evtl. gar keine highway-typen korrigieren. >das highway ist aber trotzdem notwendig, um anzugeben, dass es eine strasse >ist, und kein gleis/fluss/... Deshalb: "road". Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
Gerald.Oppen wrote: >Nach Deiner Argumentation wäre eine "primary" auch keine Strasse wenn sie >für LKWs durch ein entsprechendes Flag gesperrt ist(z.B. wegen den >Mautflüchtlingen). >Oder willst Du den highway-tag nur auf die Anwendung für PKWs beschränken? Nein. Aber meine Argumentation lautet ja auch: "Setze highway=primary nur dann, wenn auch ein Primary-Highway existiert. Eine Baustelle oder gar nur ein Plan *ist kein* Primary-Highway"." Straßensperren für LKWs ändern dagegen nichts an der realen Existenz der Straße. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
Guenther Meyer wrote: >das highway-tag in der form ist mir eh schon lange ein dorn im auge... >da muss man nicht noch mehr reinpacken, und es noch schwammiger machen. Schwammig wird der highway-tag, wenn man zusätzlich noch andere tags auspressen muss um seine Bedeutung zu ermitteln. Norbert (Dass der Name "highway" für alle Arten von Tracks nicht glücklich ist, sei unbenommen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
Guenther Meyer wrote: >warum dann ueber das highway-tag? Weil genau dieses tag die Art des Objektes beschreibt. >das besitzt werte wie "motorway", "primary", "secondary", "residential", ... >sowas wie "planned" oder "under construction" passt rein semantisch schon gar >nicht da rein. IMHO muß diese Information aber genau dort hinein. Für den IST-Zustand bedeuten diese Inhalte nämlich: "Dies ist (noch) gar keine Straße!" Bei nicht vorhandenen Straßen die Standardwerte einzutragen würde die Semantik des highway-tags verändern (verwässern, verfälschen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
Gerald.Oppen wrote: >Unsinn ist es statische Daten dynamisch machen zu wollen und damit >zusätzlichen >Aufwand zu schaffen. Der Prozess Idee-Planung-Bau-fertige Straße ist nunmal dynamisch. Für mich muss sich das dann auch in einer Änderung des "highway"-values wiederspiegeln (sofern denn physikalisch nicht Vorhandenes überhaupt in die db gehört). Du dynamisierst statt dessen die *Bedeutung* des values (und nennst das dann "statisch"). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
Guenther Meyer wrote: >sorry, aber diese herangehensweise erscheint mir unlogisch. >ein highway=primary und was in der art construction=yes sollte das ganze >sinnvoll beschreiben. Warum ich das für falsch halte, habe ich ja schon geschrieben: >> Wenn eine Baustelle mit "highway=primary" getagged würde, dann wäre >> plötzlich die Bedeutung dieses Eintrages geändert. Bisher ist >> "highway=primary" eine größere befahrbare Straße. Wäre "construction" ein >> zusätzlicher key, dann können sich plötzlich auch noch Schlammwüsten, Pläne >> in einer Schublade oder unausgegorene Ideen in den Köpfen einiger Leute >> dahinter verbergen. >> >... und wenn construction gesetzt ist, dann WIRD das eine entsprechende >strasse. wenn alles fertig gebaut ist, einfach das construction flag >entfernen, und gut is. ... und die Routingprogramme müssen wissen, dass "highway=primary" nicht immer zum Routing herangezogen werden darf (und so weiter und so fort). Wenn es (noch) keine Straße ist, dann halte ich es für Unsinn es als Straße zu taggen und noch "Ausnahmekeys" zu erfinden. >die renderer muessens dann halt auch entsprechend darstellen. Und das würden sie auch tun, wenn du nicht eine andere als die schon genutzte Methode Baustellen zu kennzeichnen verwenden würdest. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
Gerald.Oppen wrote: >Das ist so Murks! >Der Strassentyp steht in der Regel schon mit der ersten Planung fest. >So wurden mir schon einige meiner Einträge für in Bau oder Planung >befindlichen Strassen wieder überschrieben >und damit in meinen sämtlichen verwendeten Anwendungen wieder unsichtbar >gemacht die ich bereits in der Praxis >verwende- auch um bei diversen baupolitischen Entscheidungsträgern zu >zeigen was mit OSM geht! >Mit "highway=construction" wird der Vorteil von OSM die aktuellen >(Planungs-)Zustände wiederzugeben zu nichte gemacht. Zu "highway=construction" gehört deshalb ja auch "construction=primary" bzw. das Zutreffende. >Meiner Meinung nach muss "construction" ein Flag sein - Vorzugsweise mit >einem Wert für "In Plannung" >und "In Bau" der dann den Renderer anweisst die Strasse gestrichelt >bzw. transparent darzustellen wie Wenn eine Baustelle mit "highway=primary" getagged würde, dann wäre plötzlich die Bedeutung dieses Eintrages geändert. Bisher ist "highway=primary" eine größere befahrbare Straße. Wäre "construction" ein zusätzlicher key, dann können sich plötzlich auch noch Schlammwüsten, Pläne in einer Schublade oder unausgegorene Ideen in den Köpfen einiger Leute dahinter verbergen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Darstellung von Getränkemärkten
Christoph Eckert wrote:
> Zwar ist es als Motivationshilfe
>unverzichtbar, aber wir mappen doch, um die Daten hinterher für ganz
>verschiedene Anwendungen zur Verfügung zu haben. Navigation beispielsweise
>("show me the way to the next beverages store"). Oder Garmin-Karten. Oder
>eigene Druckwerke. Bei all diesen Sachen ist es unerheblich, ob der
>Getränkemarkt, den ich eingetragen habe, vorher auf der Slippymap auftauchte
>oder nicht. Wichtig ist, dass die Information da ist.
Für /eigene/ Druckwerke mag das gelten (dann wird OSM aber nur als
kostenloser Speicherplatz benutzt. Aber in all deinen anderen Beispielen
hilft eine "private" Bezeichnung gar nichts. /Information/ wird eine
Zeichenkette erst dann, wenn sie mit einer festgelegten Bedeutung verknüpft
wird. Und die Stelle, an der diese Verknüpfung bisher vorgenommen wird, ist
"Map Features".
Norbert
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Radwanderwege, Flussbreite, Zoomstufen, josm
Andreas Jacob wrote: >Zoomstufen >Wie ist eigentlich der zeitliche Rahmen für das Rendern der Zoomstufen >ab 11 abwärts (10, 9 etc.)? Einmal wöchentlich scheinen diese nicht >gerendert zu werden. In der Mapnik-Karte werden auch die niedrigen Zoomstufen AFAIK wöchentlich neu gerendert. Bei [EMAIL PROTECTED] gibt es keinen festen Zeitrahmen. Wer kann und will rendert mal einige Tiles und das auch noch nach ganz unterschiedlichen Regeln. Als besonders anschauliches Beispiel siehe: http://tah.openstreetmap.org/Browse/?x=134&y=92&z=8&layer=tile (dort sind in den 9 angezeigten Kacheln wohl 4 unterschiedliche lowzoom-Versionen im *aktuellen* Einsatz. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
