Re: [Talk-de] Wiederherstellung von Nodes, ID unbekannt
Hallo Cottaer, gibt es einen Weg, gelöschte Objekte wiederherzustellen? Es handelt sich um einen Node, die ID ist mir unbekannt. Solche Objekte findet man - insbesondere bei dem ungewöhnlichen Namen - häufig auch via Google: http://www.google.com/search?q=Struppengrundkegel+openstreetmap 1. Suchergebnis: http://www.strassenkatalog.de/osm/struppengrundkegel,1259440632n.html = Node mit der ID 1259440632 http://www.openstreetmap.org/browse/node/1259440632 Gruss, Thomas -- http://rollstuhlkarte.ch/ - jetzt mit aktuellem ÖPNV-Fahrplan. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radwege-Spezis
Hallo zusammen, Unter anderem auf der Seite: http://osm.t-i.ch/bicycle/map/ wie müsste man es eintragen, damit es dort ausgewertet wird: mehrere Werte im gleichen Schlüssel, oder cycleway:surface und footway:surface? Oder geht beides? Wahrscheinlich gar nicht. Ein Wert im Schluessel surface, denk ich mal. Genau - ich hab's in der Legende nun präzisiert. Allerdings werden momentan offenbar gar keine surface-Linien eingezeichnet. Irgendwie scheint da beim letzten Toolserver-Update etwas kaputt gegangen zu sein.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umsatzsteuer-nummern taggen
Hallo Martin, ist auch so im Wiki dokumentiert: http://wiki.openstreetmap.org/wiki/Key:ref:vatin also ohne Doppelpunkt nach dem Länderkürzel, da dieser in der offiziellen internationalen Schreibweise der Steuernummer auch nicht vorgesehen ist. Parallel zu unserem Schema ist wohl derzeit noch mind. ein weiteres Schema in Gebrauch (aktuell 60x verwendet), nämlich operator:tax http://taginfo.openstreetmap.org/keys/ref%3Avatin#values http://taginfo.openstreetmap.org/keys/operator%3Atax#values Ohne über Sinn bzw. Unsinn des Taggings mitzudiskutieren: http://taginfo.openstreetmap.org/keys/ref%3Ait%3Avat#values (102x) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Karte für Fahrradrouten
Zitat von Sven Geggus li...@fuchsschwanzdomain.de: Und wie soll das bitte technisch funtionieren ohne neue Kacheln zu rendern? Opacity kann man bei Openlayers AFAIK nur bei Overlays verändern. Das geht ohne Probleme auch für 'normale' Layer: http://rollstuhlkarte.ch/ Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schweizer Grenzen (war: Re: openstreetmap und qgis)
Hallo Markus, Ja, das kann ich mir vorstellen! Wie ist denn der aktuelle Stand? In einem Monat sollten die Daten in der OSM-Datenbank sein: http://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#2._Mapping_Party_Rapperswil_und_20._OSM-Treffen Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzeigenfehler bei Mapnik
Hallo Steffen, ich meine hier schon mal so was gelesen zu haben, finde es aber nicht. Wenn ich Firefox (4) benutze hat ich einige Kachenl im Bild mit ... more OSM comming soon je nach Vergrößerung liegen die anderswo. Entweder Claudius' Lösung oder es liegt daran, dass Du einen der Tile-Server versehentlich blockiert hast. Löschen kannst Du die Sperre hier: 'Einstellungen' - Tab 'Inhalt' - Button 'Ausnahmen...' hinter 'Grafiken laden' - alle Websites mit openstreetmap.org im Namen aus der Liste entfernen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wikifiddling, access car / motor_car
Zitat von M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 9. Mai 2011 14:50 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: Es gab aber bereits seit 2008 eine Seite speziell für motorcar, auf der wie heute auch noch klar das steht, was bis dahin Konsens und Definition war (Description: Access permission for cars.). http://wiki.openstreetmap.org/w/index.php?title=Key:motorcaroldid=194411 Wenn im Wiki auf zwei unterschiedlichen Seiten verschiedene Definitionen stehen, dann kann man IMHO nicht von 'klar' und 'Konsens' reden. Zumal die Access-Seite wahrscheinlich häufiger besucht wird als diejenige für Motorcar und meine Anpassung monatelang stehen blieb. (Natürlich kann das auch heissen, dass sich einfach niemand für das Thema interessierte.. :-) Ich glaube auch, dass die Hierarchie-Stufe 'zweispurige Motorfahrzeuge' notwendig ist (sofern man denn eine Hierarchie haben will). ja, sehe ich auch als sinnvoll an. Na immerhin hier sind wir uns einig.. ;) Ob 'motorcar' der geeignete Begriff ist? Darüber lässt sich natürlich gut streiten - naja, da der Begriff (in OSM) schon für Autos belegt ist, würde ich ehrlich gesagt was anderes nehmen und finde auch nicht, dass man da besonders gut drüber streiten kann. Das sehe ich - wie bereits nachfolgend geschrieben - nicht so. Das 'Verbotsschild mit dem Auto' steht in den meisten Ländern für *alle zweispurigen Motorfahrzeuge*. Da ich bisher kein Land kenne, in welchem es ein Verbotsschild gibt, das nur für Autos und nicht für LKWs gilt, gehe ich davon aus, dass die alleremeisten highway=* mit motorcar=no eines der oben verlinkten Verbotsschilder haben - und somit übereinstimmend mit der 'meiner' Wiki-Version getagged sind. Es gibt ein Gebotsschild z.B. beim Parken. Mir ist hier auch bereits ein Freitext-Schild aufgefallen, das die Einfahrt durch jegliche Verkehrs untersagt, und dann im Textteil (ausser Autos) die Autos wieder ausnimmt ( http://www.23hq.com/dieterdreist/photo/6059575 ) Darum schrieb ich oben von 'highway=*'. Die 212'866 motorcar-Keys sind zu fast 90% zusammen mit highway=* vergeben, aber nur zu unter 1% zusammen mit amenity=*. Trotz Deinem Gegenbeispiel aus Italien bleibe ich bei der Überzeugung, dass 'motorcar' bisher hauptsächlich für zweispurige Motorfahrzeuge genutzt wird. IMHO brauchen wir also einen neuen Key für Autos - und nicht eine 'Rückverschiebung' von motorcar. -1, Ich wiederhole mich da zwar, aber am Argument ändert sich nichts: es ist niemandem nahezubringen, dass motorcar alle 2-spurigen Fahrzeuge beinhalten soll und car nur Autos. Die tags sollten sich auch mit gesundem Menschenverstand lesen lassen können, und zumindest nicht irreführend sein. Von 'car' habe ich nirgends etwas geschrieben - das fände ich nämlich (insbesondere parallel zu 'motorcar') auch schlecht. Gefallen würde mir hingegen das wieder aus dem Wiki verschwundene 'automobile'; das sollte genügend international sein um überall verstanden zu werden. Da wir in der ganzen Access-Hierarchie schon einige Abkürzungen (hgv, psv, ...) haben, könnte ich auch mit einem neuen Kürzel für zweispurige Kraftfahrzeuge (und der gleichzeitigen Abschaffung von 'motorcar') leben.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wikifiddling, access car / motor_car
Zitat von M∡rtin Koppenhoefer dieterdre...@gmail.com: Nach wie vor finde ich es inakzeptabel, wenn ein access-tag (oder sonst ein tag, wobei access halt zu den Stammtags gehört) ohne Ankündigung oder Diskussion einfach so im Wiki in seiner Bedeutung verändert wird. Als dieser ominöse Änderer möcht ich auch noch was dazu sagen. ;-) Auf der access-Wiki-Seite stand und steht hinter motorcar als nähere Beschreibung motor vehicles with more than 2 wheels/more than 1 track - und da gehören LKWs zweifelsohne mit dazu. Für mich war es daher nichts als logisch, die Hierarchie der Beschreibung (übereinstimmend mit der deutschen Wiki-Seite) anzupassen. Ich glaube auch, dass die Hierarchie-Stufe 'zweispurige Motorfahrzeuge' notwendig ist (sofern man denn eine Hierarchie haben will). Ob 'motorcar' der geeignete Begriff ist? Darüber lässt sich natürlich gut streiten - allerdings wird das Auto (von vorne) häufig verwendet, um die Durchfahrt von zweispurigen Kraftfahrzeugen zu verbieten: http://en.wikipedia.org/wiki/Comparison_of_European_traffic_signs [Die Beschreibung für UK ist übrigens verkürzt, auch dort dürfen 'solo motor cycles' weiterfahren.] Da ich bisher kein Land kenne, in welchem es ein Verbotsschild gibt, das nur für Autos und nicht für LKWs gilt, gehe ich davon aus, dass die alleremeisten highway=* mit motorcar=no eines der oben verlinkten Verbotsschilder haben - und somit übereinstimmend mit der 'meiner' Wiki-Version getagged sind. IMHO brauchen wir also einen neuen Key für Autos - und nicht eine 'Rückverschiebung' von motorcar. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Hallo Chris, bei OSM ist es aber üblich den inner-Rings Tags für die innere Fläche zu verpassen. Beispiel: outer = Waldgebiet inner1 = Acker inner2 = Heide Der Acker grenzt direkt an die Heide. Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? +---+ | Wald | | ++-+| | || || | | Acker | Heide || | || || | ++-+| | | +---+ Wenn Du möchtest, dass der OSMI keine Warnmeldung mehr anzeigt, dann musst Du 3 Relationen erstellen: WWW W Wald W WAAXHHW WA X HW WA Acker X Heide HW WA X HW WAAXHHW W W WWW Relation 1: Wald mit Way W als outer und Ways A, H als inner Relation 2: Acker mit Ways A, X als outer Relation 3: Heide mit Ways H, X als outer Die Ways selber erhalten keine Tags. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] n paar Fragen
Hallo zusammen, Einfacher Fall in der Realität: Gebäude mit einer Adresse, alle Eingänge des Gebäudes und die Läden darin haben auch diese Adresse. Umsetzung in OSM: Gebäudeumriss mit Adress-Tags versehen, Nodes für die Läden ins Innere der Fläche und ggf. Eingänge in die Umrandung setzen. Können wir erst einmal festhalten, dass das in diesem normalen Fall ausreicht? Damit wäre die eigentliche Frage nämlich beantwortet. Einmal mehr plädiere ich dafür, dass *jedes* Geschäft/Node innerhalb des Gebäudes mit der kompletten Adresse getagged wird. Gerade bei Seiten wie der OLM ist dies sehr praktisch: http://olm.openstreetmap.de/?zoom=18lat=48.14101lon=11.58896layers=B0FTT Bei Adressen ist der Konsens ja bereits, dass ein bisschen Redundanz nicht schadet (addr:city, ...), da sollten die zusätzlich getaggeden Nodes auch nicht stören.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Teilnehmervereinbarung 1.2.4
Hallo zusammen, da sich seit der Version 1.0 einiges geändert hat, habe ich die aktuelle Teilnehmervereinbarung 1.2.4 neu übersetzt: http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Contributor_Terms Ich hoffe, die Übersetzung ist verständlich un korrekt - Verbesserungen können direkt im Wiki angebracht werden. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei Postgres Installation für Osmosis
Hallo Alex,
psql:script/pgsql_simple_schema_0.6.sql:40: FEHLER:
AddGeometryColumns() - invalid SRID
KONTEXT: SQL statement SELECT AddGeometryColumn('','', $1 , $2 , $3 ,
$4 , $5 )
PL/pgSQL-Funktion »addgeometrycolumn« Zeile 4 bei SQL-Anweisung
Ich habe heute Nachmittag ebenfalls mit Osmosis herumgespielt und
wollte das Wiki eigentlich heute Abend verbessern:
Du benötigst noch die spatial_ref_sys.sql, ebenfalls im
contrib-Verzeichnis von PostgreSQL:
psql -d test -f /usr/share/postgresql/8.4/contrib/postgis.sql
psql -d test -f /usr/share/postgresql/8.4/contrib/spatial_ref_sys.sql
psql -d test -f /usr/share/postgresql/8.4/contrib/hstore.sql
psql -d test -f script/pgsql_simple_schema_0.6.sql
Gruss,
Thomas
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Karte: rollstuhlkarte.ch
Hallo zusammen, Neues Jahr, neue Karte: http://www.rollstuhlkarte.ch/ Die verfügbaren Layer: - Toiletten: Neben der rollstulgängigkeit (wheelchair=yes) wird auch angezeigt, ob die Toilette mit einem Eurokey (centralkey=eurokey) bzw. (nur) gegen Gebühr (fee=yes) geöffnet werden kann. - Parkplätze: Neben 'herkömmlichen' Parkplätzen (amenity=parking) mit speziell ausgewiesenen Parkfeldern für Rollstuhlfahrer (capacity:disabled=*), wertet die Karte auch 'alleinstehende' Parkplätze aus, welche extra für Rollstuhlfahrer erstellt wurden (entweder amenity=parking mit capacity=zahl und capacity:disabled=gleiche zahl, z.B: capacity=1 und capacity:disabled=1 oder aber *neues Tagging* amenity=parking_space parking_space=disabled [siehe dazu Tagging-Vorschlag von Geonick: http://wiki.openstreetmap.org/wiki/User:Geonick/Parking ]) - Geschäfte: Alle amenity=[shop|bank] werden mit einer entsprechenden Farbe (grün/orange/rot) hinterlegt. Ein Rendering der Icons auf jeder Zoom- stufe folgt noch. - Freizeit: Alle amenity=[cinema|theatre|museum|pub|bar|cafe|restaurant|nightclub] werden mit einer entsprechenden Farbe (grün/orange/rot) hinterlegt. Zusätzlich werden folgende Keys ausgewertet: wheelchair:places=* wheelchair:toilets=* wheelchair:description=* wheelchair:source=* http://wiki.openstreetmap.org/wiki/DE:Key:wheelchair - Eingänge: building=entrance mit wheelchair=* werden ausgewertet. Beispiel: Historisches Museum Bern http://www.rollstuhlkarte.ch/?zoom=18lat=46.94307lon=7.44919layers=B0FTFTTT - Wanderwege: Relationen mit route=wheelchair. Leider funktioniert hier das Popup noch nicht.. Bsp: http://www.rollstuhlkarte.ch/?zoom=14lat=47.34256lon=8.70171layers=B0FTFFFT - Tram-/Bus-Linien: Relationen mit route=[tram|bus] und wheelchair=* werden ausgewertet. - Tram-Haltestellen: Haltestellen (railway=tram_stop) werden ausgewertet. Eine Erweiterung auf das neue Schema (public_transport=platform) folgt noch. Technik: Die Daten werden über einen Proxy auf dem Toolserver von Wikimedia abgefragt und als GeoJSON-Objekte übertragen. Momentan wird lokal noch nichts gecached; es kann daher schon mal sein, dass eine Abfrage ab- bricht und gar nichts auf der Karte angezeigt wird. In einem solchen Fall bitte einfach unten rechts auf 'Permalink' klicken, um die Abfrage neu zu senden. Zukunft: - Internationalisierung (Übersetzung in andere Sprachen) - Download von POIs für Navis - Genauere Angaben für Haltestellen - ...? Mein Testgebiet war bisher vorallem die Stadt Zürich. Da das Detail- Tagging z.B. von Toiletten bisher noch nicht sehr einheitlich ist, ist es wahrscheinlich, dass die Popups in anderen Städten 'komische' Resultate anzeigen. Hier nehme ich gerne Feedback entgegen und werde auch versuchen, die entsprechenden Wiki-Seiten anzupassen/zu erweitern. Zum Schluss möchte ich Alexander Matheisen danken, dessen OpenLinkMap als Grundgerüst diente, sowie dem Wikimedia-Team, welches den Tool- server betreut und bei SQL-Fragen immer zu helfen wusste. Gruss und ein frohes Neues! Thomas http://wiki.openstreetmap.org/wiki/Rollstuhlkarte.ch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Karte: rollstuhlkarte.ch
Nachtrag: Technik: Die Daten werden über einen Proxy auf dem Toolserver von Wikimedia abgefragt und als GeoJSON-Objekte übertragen. Momentan wird lokal noch nichts gecached; es kann daher schon mal sein, dass eine Abfrage ab- bricht und gar nichts auf der Karte angezeigt wird. In einem solchen Fall bitte einfach unten rechts auf 'Permalink' klicken, um die Abfrage neu zu senden. Bevor jemand fragt, wie aktuell die angezeigten Daten sind: Normalerweise werden die Daten jeweils innerhalb von wenigen Minuten angezeigt, momentan scheint das Update allerdings nicht zu funktio- nieren: http://munin.toolserver.org/OSM/ptolemy/replication_delay2.html Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerhaftes Auswerten von Abzweig-Relationen?
Hallo zusammen, Wer lust hat in ganz Europa etwas mit wohl defekten Abbiegerelation zu arbeiten ... http://dev.openstreetmap.de/aio/mkgmap-errors/20101122/1_RestrictionRelation.txt Wer lieber nur in seiner Umgebung mappt, der findet Abbiege-Fehler auf dieser Karte: http://osm.virtuelle-loipe.de/restrictions/ Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] download.geofabrik.de überlastet ?
Hallo Frederik, Ich werde mal die PBFs fuer Deutschland und Europa ebenfalls auf den GWDG-Mirror tun. Wie wär's mit einem Hinweis auf den Mirror auf http://download.geofabrik.de/osm/ ? Momentan wird man fast nirgends darauf aufmerksam gemacht, dass man die Dateien auch von anderswo herunterladen könnte.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sperre für Oberförster?
Hallo Georg, Genau, zeigt auf Mapnik *alles* an, was irgendwie darstellbar oder auswertbar ist - dann kann sich zumindest keiner mehr beschweren, dass er etwas nicht findet ... und jeder kann ihm dann auf die Finger hauen, das er es nur nicht gefunden hat ... Ich möchte übrigens auch auf der Karte erkennen können - wo man reiten darf und wo nicht - wo man mit dem PKW fahren darf und wo nicht - wo man mit dem LKW fahren darf und wo nicht Ich arbeite zur Zeit auf dem Toolserver an einem bzw. vielen Layern, welche genau diese access-rights farblich darstellen. Sobald die Last auf dem Toolserver wieder etwas ausgeglichener ist(*), werde ich den Link hier posten. Gruss, Thomas (*) Wir sind noch auf der Suche nach der richtigen Strategie, wann und wie oft die Tiles der verschiedenen Karten neu gerendert werden sollen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Textlose Karte (war: Re: Mehrsprachige Tiles)
Hallo Robert, Ja, bei der Wikipedia: http://toolserver.org/~osm/locale/http://toolserver.org/%7Eosm/locale/ Wobei mir da der völlig Textfreie Layer ganz toll gefällt. Gibt es da irgendwo den Kartenstil? Alle Styles, die auf dem Toolserver gerendert werden, findest Du hier: http://svn.toolserver.org/svnroot/p_osm/styles/ Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für Farbenblinde (Was: Re : Neu: Ein schwarz/weißer Base-Layer)
Hallo Kay, Eine Karte nach deinem Wunsch ist bestimmt möglich, aber nur schwer automatisch hinzubekommen. Dazu bräuchte es mehr Wissen um die (verschiedenen möglichen) Farbschwächen. Ich bin per Zufall vor ein paar Tagen über diese Seite hier gestolpert: http://gmazzocato.altervista.org/colorwheel/wheel.php Vielleicht hilft sie ja dem einen oder andren hier beim Erstellen seiner Karten.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hallo Ulf und Kay, Wie wäre es mit nem schwarzen Ring für den Schlauch und innen drin ein paar Münzen für den Automaten? danke für die Ideen! :) Es gibt jetzt einen Layer mit Schlauchomaten (vending=bicycle_tube; schwarzer Kreis) und Pump-Stationen (amenity=compressed_air bzw. compressed_air=yes; Pneu-Ausschnitt mit Ventil). Popup mit weiteren Informationen baue ich noch ein.. http://osm.t-i.ch/bicycle/map/?zoom=14lat=47.35lon=8.66layers=000B00TTT Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Schließfach
Hallo Jan, ich habe in der letzten Zeit mehrfach schon so Boxen für Fahrräder (Art Schließfach) gesehen - Velobox habe ich als Bezeichnung schon einmal dazu gelesen. amenity=bicycle_parking bicycle_parking=lockers capacity=* http://wiki.openstreetmap.org/wiki/Key:bicycle_parking Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hallo Kay, Ein Komplettbeispiel mit hillshading und Bicycle-Layer: http://toolserver.org/~osm/styles/?zoom=15lat=47.6322lon=13.00511layers=F0FTF0TF0B Sehr schön! Damit erreicht man, was ich mit meinem 20%igen Mapnik-Layer versucht habe - nur viel besser! ;-) Auf meiner Karte findet man ab den schwarz/weiss-Stil daher ab sofort auch: http://osm.t-i.ch/bicycle/map/ BTW: Irgendwer 'ne Idee, was man für die Fahrradschlauchverkaufsauto- maten für ein Icon verwenden könnte? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Heiko, Die weissen Striche ohne Access-Umrandung sind eigentlich ungewolltes Nebenprodukt, daher müssen sie gar nicht sichtbar sein.. ;-) Man kann sich streiten, ob tracks wirklich auch noch die zugehöreigen access-tags brauchen, aber geschotterte residential, service, unclassified, ... (und höhere abseits Europa), die für alle offen sind, brauchen nun wirklich keine ... Vielleicht haben wir uns falsch verstanden - ich wollte damit sagen: Die weissen Linien sollten (bei meinem Style) nur dort angezeigt werden, wo auch access-Werte vorhanden sind. Bei den Tracks ohne access-Werte soll man wie bisher auf die Renderer-Darstellung von grade1-5 schauen. Inzwischen habe ich testehalber einen hazard-POI-Layer gebastelt: http://osm.t-i.ch/bicycle/map/ Er erkennt hazard (Ausrufezeichen) sowie hazard:bicycle und cycling_hazard (Fahrrad) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Heiko, am Dienstag, 12. Oktober 2010 um 21:48 schrieben Sie: Am 11.10.2010 12:01, schrieb Thomas Ineichen: Weiss für verfestigte/bearbeitete Oberflächen Mir fällt gerade auf, dass weiß etwas suboptimal kommt ... Gelb vielleicht besser? Ansonsten hübsch ;-) Die weissen Striche ohne Access-Umrandung sind eigentlich ungewolltes Nebenprodukt, daher müssen sie gar nicht sichtbar sein.. ;-) Ginge noch Osmarender als weitere wählbare Hintergrundkarte? In den besseren Zoomstufen sind Feld-/Rad-/Gehwege darin nicht nur dünne Striche, sondern breit, so dass man evtl. den Basisweg besser erkennen könnte. Ist integriert. Zusätzlich kann man auch meinen Layer aufhellen (20%), so dass die dahinterliegende Karte besser durchscheint. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Steffen, Kommt eigentlich auf das Kopfsteinpflaster an. Wenn es einigermassen eben ist, dann stimm ich dir zu. Wenn es aber von Stein zu Stein Hoehenunterschiede von 5cm gibt, dann ist's wenigstens weiss, wenn nicht schon rot. Wahrscheinlich bin ich hier in der Schweiz einfach zu verwöhnt. Leider haben von den 67'143 cobblestone-highways nur gerade 1'444 eine Smoothness-Angabe: http://toolserver.org/~ti/cobblestone.txt Ich bastle gerade an einer anderen Anwendung, bei der Oberflächen wichtiger sind, ev. fallen von dort ein paar Code-Schnipsel ab. Bis dahin werde ich cobblestone auf schwarz/weiss ändern. Grau? Also Mischfarben zwischen den drei gewaehlten Farben, je nach Auspraegung mal mehr die eine, mal mehr die andere. Macht das aber auch nicht uebersichtlicher, wenn erstmal 100 Abstufungen eingetragen sind. Und dann gibt's dafür die Diskussionen, ob ein gravel-Weg mit good heller oder dunkler sein sollte als ein compacted-Weg mit inter- mediate :- SELECT smoothness, surface, count WHERE tags ? 'surface' GROUP BY smoothness, surface http://toolserver.org/~ti/smoothness_surface.txt Wenn du irgendwie XAPI oder Datenbank abfragst mit Select * where surface=key, dann nicht. Wenn du aber irgendwann den vollstaendigen Weg sowieso in die Hand nimmst, dann kannst du s/;.*// anwenden und nur den ersten Eintrag parsen. Wenn, dann möchte ich aber den 'schlechtesten' der Tags erkennen, um den Weg entsprechend hell einzufärben. Soviel Qualität muss sein. ;-) Beschriftungen wuerde ich vermeiden wollen. Ich haett's als halbes oder ganzes Verbot gewertet. Wenn du willst: Stricheln mit entsprechender Laenge der Striche und Luecken ;-) Wir hatten vorgestern am Zürcher Stammtisch eine Präsentation/Diskus- sion mit dem Chef von OCAD[1], einer Kartographie-Software - Fazit: In schönen und ansprechenden Karten steckt verdammt viel Arbeit.. Eins fiel mir noch auf: Die bicycle=permissive werden nicht dargestellt. In der Legende steht bicycle=permessive, vielleicht ist der Tippfehler auch im Programmcode? Das schreibe ich ständig falsch, obwohl ich eigentlich weiss, dass es von 'permission' kommt.. :-/ Der Stil ist aktualisiert und stellt jetzt auch Motorfahrzeug-Verbote in hellblau dar. Die Caching-Strategie von Tirex sorgt aber offenbar dafür, dass die Kacheln nicht sofort neu gerendert werden.. Gruss, Thomas [1] http://ocad.ch/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Steffen, http://access.t-i.ch/extended-bicycle.html Neu ist insbesondere die dünne Mittellinie, welche die Oberfläche visualisiert: Schwarz für gescholssene/geteerte Oberflächen Weiss für verfestigte/bearbeitete Oberflächen Rot für naturbelassene Oberflächen Cool. Ein Wunsch: Ich wuerde surface=cobblestone etwas niedriger einordnen. Beim Kopfsteinpflaster war ich mir auch unsicher, wo ich es einordnen soll; gerade bei Regen gibt es viele solcher Strassen, die dann unangenehm zu befahren sind. Trotzdem gehört es nicht in die 'weisse' Kategorie.. wahrscheinlich ändere ich das zu schwarz gestrichelt o.ä. Und ein paar Fragen: Schaust du auch nach smoothness? Oder beruecksichtigst du surface=concrete_plates? Oder surface=paving_stones:20 usw.? Nein und nein. :) @smoothness Irgendwann wird's einfach zu eng auf der Karte. Ich könnte mir höchstens vorstellen, dass gewisse surface-Werte die schwarzen Linien zu gestrichelten Linien abwerten (ähnlich wie cobblestone) - oder hast Du eine gute Visualisierungs-Idee? @surface: Ich habe mich vorerst auf die 15 häufigsten Werte beschränkt: http://toolserver.org/~ti/surface.txt BTW: wäre surface=paving_stone, paving_stone:dimension=20x20 nicht besser? Wäre zumindest einfacher auswertbar (zumindest für meine Karte, da ich die Diemension vorerst eh nicht beachten würde :- ) Mit Bezug auf den Semikolon-Thread: Kommst du mit surface=grass;ground und so klar? Nein - ich glaube, das ist hier aber auch nicht so einfach. (Bei der Küchen-Karte kannst Du z.B. nach dem Substring 'italian' suchen für italienische Küche (ausser ein Depp schreibt cuisine=not italian..). Bei surface gibt es aber so Sachen wie 'fine_gravel', was ich eine Stufe höher einordnen würde als gravel etc.) Hmm, bicycle:hour_on und hour_off fiele mir noch ein, aber das wird wohl etwas zu weit fuehren. DAS hingegen wäre schon wieder einfacher - einfach als String dranpappen. Wäre ein Versuch wert, mit Beschriftungen habe ich bisher noch nie gearbeitet.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo zusammen, Auf dem Toolserver werkelt inzwischen Tirex, daher sollten veraltete Kacheln der Vergangenheit angehören. Grund genug, meine Fahrrad-Karte zu überarbeiten: http://access.t-i.ch/extended-bicycle.html Neu ist insbesondere die dünne Mittellinie, welche die Oberfläche visualisiert: Schwarz für gescholssene/geteerte Oberflächen Weiss für verfestigte/bearbeitete Oberflächen Rot für naturbelassene Oberflächen schönes Beispiel: http://access.t-i.ch/extended-bicycle.html?zoom=17lat=47.39758lon=8.54614layers=B000T Wünsche, Anregungen und Fehlermeldungen bitte hier oder auf der Wiki- Seite: http://wiki.openstreetmap.org/wiki/User:T-i/Access-Map Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertengerechte Parkplätze
Hallo Jan, ich habe gerade gesehe das im JOSM behindertenger. Parkplätze mit capacity:disabled gekennzeichnet werden. [...] wenn ich nur einen Stellplatz irgendwo in der Stadt habe - den normalen Parkplatz mit dem o.g. Tag =1 kennzeichnen oder gibt es was anderes noch ?? Bei einzelnen Stellplätzen bitte *immer* auch noch capacity=1 eintra- gen, damit die Renderer überhaupt eine Chance haben, solche Parkplätze anders bzw. gar nicht zu rendern. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mittelsachsen-Atlas auf Basis von OSM
Hallo Jan, Beides - sowohl die Hillshades als auch die OSM-Tiles - wäre für ein so kleines Gebiet durchaus mit vertretbarem Aufwand selber herstellbar.. du schreibst mit vertretbarem Aufwand selber herstellbar.. - kannst du das etwas konkretisieren da vielleicht soetwas auch für andere interessant sein könnte. Es kommt halt immer auf die Definition von vertretbar an. ;-) (Und ich weiss weder, wie gross der verursachte Traffic ist, noch, ob irgendwelche Gespräche geführt wurden!) Ein Gebiet in der Grösse von Mittelsachsen rendere ich auf meinem normalen Büro-PC (inkl. Import des Planet-Ausschnittes) in ca. einem halben Tag. Anleitung gibt's z.B. hier: http://weait.com/content/build-your-own-openstreetmap-server Da keine minütliche Aktuallisierung gewünscht ist, kann der Renderer im internen Netzwerk (1x pro Woche?) laufen und die Tiles anschliessend auf den Hauptserver kopiert werden. Die Hillshades ändern nicht ständig, man könnte sie daher: a) selber rendern (zugegeben, kompliziert) b) länger cachen (1 Monat? 6 Monate? 1 Jahr?) c) Colin fragen, ob er eine Zip-Datei der Region zur Verfügung stellt Wie gesagt liegt es aber zum Glück nicht an mir, darüber zu entscheiden, welche Last für OSM bzw. Wikimedia/Toolserver noch tragbar ist. :) Wer weiss, vielleicht wird ja in einer der nächsten Versionen ein eigener Renderer eingebaut? http://www.mittelsachsen-atlas.de/downloads/ immer so ein postgis und mapnik finde ich persönlich sehr aufwendig um es auch zu verargumentieren gegenüber google als alternative. Ich weiss nicht, wie die Vermessung in Deutschland organisiert ist, aber auf der Ebene Landkreis sollte das kein Hinderungsgrund sein. (Man hat ja auch die Vorteile von FOSS richtig erkannt!) Natürlich soll und muss andererseits der 2. Vorsitzende des Wandervereins Hintertupfingen, der seine drei Wanderrouten darstellen möchte, auf die öffentlichen OSM-Tileserver zurückgreifen, dafür sind sie ja da. Wo die Grenze zu ziehen ist? Schwierig zu sagen. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Hallo Garry, Denkt doch mal darüber nach wofür die Daten benötigt werden und wie sie eingesetzt werden! Es ist schön wenn man zu Hause als OSM-Profi mit einem Linuxrechner der am Netz hängt selbst seine Auswerteskripte seinen Wünschen entsprechend anpassen kann und beliebige Filter für Eingabefehler dazu setzen kann. Nur brauch man die Daten dort am wenigsten! Und unterwegs - gerade da wo man die Daten brauch - hat man diese Ausrüstung in der Regel nicht, abgesehen davon dass die wenigsten Datenbenötiger mit den Skripten umgehen können! Für die *Auswertung* der Daten, die über Hier gibt's eine Tankstelle hinausgeht, wird man fast immer einen OSM-Profi benötigen. Diejenigen, welche z.B. die Garmin-Images erstellen. Im 'schlechtesten' Fall werden alle Key/Tag-Kombinationen des Tankstellen-Nodes als Fliesstext angezeigt. Also Tankstelle: brand=Shell // fuel:diesel=yes // fuel:octane_95=yes // shop=yes // payment=cash;maestro;mastercard;dkv // payment:2200-0700h=vending_machine // vending_machine:payment = maestro oder Tankstelle: brand=Aral // fuel:octane_91=yes // fuel:octane_95=yes // fuel:octane_100=yes // payment:cash=07:00-22:00 // payment:mastercard=07:00-22:00 // payment:dkv=07:00-22:00 // payment:maestro=24/7 Ich weiss, was ich meinem Vater lieber zu lesen geben würde. Aber das muss jeder selber entscheiden.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Distance-O-Meter
Hallo zusammen, v0.2.2: + Layer emergency zeigt jetzt auch amenity=emergency_phone + Radius wird beim Permalink übernommen + Elemente werden beim Zoomen/Verschieben automatisch neu geladen + Auch Linien und Flächen werden berücksichtigt + Elemente werden erst ab Zoom 12 angezeigt, dafür Erhöhung des Limits auf 3000 Elemente pro Layer * bekannte Fehler / Einschränkungen - Kreise sind etwas kleiner als angegeben - Limitiert auf 3000 Elemente pro Layer @Martin: Eigentlich möchte ich auf meiner Karte diejenigen Elemente anzeigen, die flächendeckend vorhanden sein sollten, wo also freie Flächen auf Nachholbedarf hindeuten.. Vielleicht kannst Du ja stattdessen mit Kolossos' Query-to-map Deine Daten finden? http://wiki.openstreetmap.org/wiki/Query-to-map Bsp: http://toolserver.org/~kolossos/qtm2/featurelist.php?key=naturalvalue=treetypes=pointsBBOX=13,52.3,13.75,55 Gruss, Thomas http://wiki.openstreetmap.org/wiki/User:T-i/Distance-O-Meter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Hallo Guenther, Die Definition war: - Ein Tag ohne Zeitraumangabe ist erstmal immer gueltig. - Einzige Ausnahme: Ist zusaetzlich nochmal derselbe Key mit einer Zeitraumangabe vorhanden, wird das allgemeine Tag durch das eingeschraenkte ersetzt. Das Hauptproblem bei dem Schema ist IMHO, ob/wie die Datenbank nach Key:[Zeitraum] durchsuchbar ist. Falls ein Programm das nicht kann, oder der Zeitraum in einem falschen Format angegeben ist, dann bleibt Dir zur Auswertung nur der Haupt-Key, und daher wäre es vorteilhaft, wenn dort das Minimum und nicht das Maximum drinstehen würde. (Bei maxspeed:wet, maxspeed:hgv sind es ja wenigstens noch feste Begriffe, die nicht so variabel sind wie Zeitangaben.) mit deiner Logik waere das: payment = maestro payment:[0700-2200h] = cash;master_card;maestro payment:[2200-0700h] = dkv geht auch, finde ich aber unnoetig aufwaendiger... Aber dafür logischer. ;-) payment:cash = 07:00-22:00 payment:mastercard = 07:00-22:00 payment:dkv = 07:00-22:00 payment:maestro = yes (oder 24/7) das blaest das Ganze halt unnoetig auf, ohne grossen Mehrwert zu bringen. Ausserdem war das Ganze dazu gedacht, eben einerseits beliebige Tag- Kombinationen mit einer Zeitangabe zu versehen, andererseits nicht nur zeitliche, sondern auch andere Einschraenkungen (die natuerlich nicht fuer jedes Tag immer sinnvoll sind) wie Gewicht, Hoehe, Laenge, Breite anbringen zu koennen. Durch die Aufgeblasenheit ist es dafür die menschenlesfreundlichste Art, die auch ein Computer noch gut verarbeiten kann. Die Subtags für die Zahlungsarten werden sich mit der Zeit genau so standardisieren wie die Tags für die verschiedenen Fahrzeugklassen.. Hängt auch vom Anwendungsfall ab: Wenn ich wissen möchte, mit welchen Mitteln ich dort bezahlen kann, können Deine Tags besser ausgewertet werden, wenn mich interessiert, ob ich mit *meiner* Karte bezahlen kann, dann kann mein Tagging einfacher ausgewertet werden. das gibt sich nicht viel... Das glaube ich Dir allerdings erst, wenn Du mir eine SQL-Abfrage für Dein Schema bastelt, welche als Resultat hat, von wann bis wann ich an einer bestimmten Tanke mit Maestero bezahlen kann. SELECT payment, (tags-'payment:maestro') AS maestro WHERE osm_id = X AND ( payment LIKE '%maestro%' OR tags ? 'payment:maestro' ) (Ungetestet.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mittelsachsen-Atlas auf Basis von OSM
Hallo Friedhelm Also zumindest bei mir kommen die Tiles von http://mittelsachsen-atlas.de/polymap/lka/osmcache ... Quote von Kolossos: die Tiles werden dabei noch nichtmal selbst gerendert, sondern kommen über einen Tile-Cache von OSM bzw. vom Toolserver. Beispiele: http://www.mittelsachsen-atlas.de/polymap/lka/osmcache/11/1094/687.png?targetBaseURL=http://tile.openstreetmap.orgexpires=432000 http://www.mittelsachsen-atlas.de/polymap/lka/osmcache/11/1100/687.png?targetBaseURL=http://toolserver.org/~cmarqu/hillexpires=432000 D.h., sie werden (wohl für 5 Tage) im Chache zwischengespeichert, *gerendert* werden sie aber nicht auf dem Mittelsachsen-Server! (Der Wikimedia Toolserver wird dabei noch nicht mal in den Nutzungsbedingungen erwähnt.) Beides - sowohl die Hillshades als auch die OSM-Tiles - wäre für ein so kleines Gebiet durchaus mit vertretbarem Aufwand selber herstellbar.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Distance-O-Meter
Hallo zusammen, Ich habe den Post-Box Guesstimator[1] etwas erweitert: http://toolserver.org/~ti/distance-o-meter/ Neben zwei zusätzlichen Layern (Telefone und Hundekottütenspender[2]) kann man den Radius der Kreise selber bestimmen. So ist es insbeson- dere in Städten mit dichtem Netz möglich, trotzdem mögliche Lücken zu finden. [Die Kreise werden IMHO etwas kleiner gezeichnet als angegeben. Warum das so ist überprüfe ich noch.] Weitere Layer werden auf Wunsch gerne aufgenommen. Gruss, Thomas [1] http://toolserver.org/~mazder/pboxguesstimator/ [2] Damit wir auch endlich eine Anwendung dafür haben.. :- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Distance-O-Meter
Hallo zusammen, Danke für die Wünsche und Hinweise; ich habe ein erstes Update gemacht: + Neue Layer: - post_office (zusammen mit post_box) - parcel_mail_in (zusammen mit parcel_pickup) - drinking_water - emergency_access_points - recycling * bekannte Fehler / Einschränkungen - Kreise sind etwas kleiner als angegeben - Radius wird beim Permalink nicht mitübernommen - Limitiert auf 300 Elemente pro Layer - ausgelassene POIs müssen beim Hereinzoomen durch Klick auf Permalink erst neu geladen werden (Hilft das, Jacques?) @Marcel Der öV ist so ergiebig, da gibt's ev. bald eine eigene Karte für.. @Andreas Operator könnte man unterscheiden, z.B. verschiedenfarbige äussere Ringe, aber eigentlich wollte ich die Karte möglichst simpel halten. Ansonsten verweise ich gerne wie auch auf der Website auf die Post- und Telefonkarte: http://post.openstreetmap.de/ Gruss, Thomas http://wiki.openstreetmap.org/wiki/User:T-i/Distance-O-Meter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteil Polynome Berlin?
Hallo Tom, übersehe ich was, oder sind die Berliner Stadtteile wirklich nur als nodes aufgeführt und nicht als Polynome mit Grenzen? Ebenso kann ich die Stadt/Landesgrenzen von Berlin nicht finden? Vielleicht findest Du hier, was Du suchst: http://tools.geofabrik.de/osmi/?view=boundarieslon=13.38641lat=52.51425zoom=11 Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Hallo Guenther, ich hatte vor laengerer Zeit mal was fuer eingeschraenkte Zufahrtsbeschraenkungen (access...) vorgeschlagen; das Schema koennte man hier auch anwenden, das waere irgendwie so: payment = cash;maestro;mastercard;dkv payment:2200-0700h = maestro oder wer's komplizierter haben will (dann waere der Automat noch mit drin): payment = cash;maestro;mastercard;dkv payment:2200-0700h = vending_machine vending_machine:payment = maestro Wenn schon, dann würde ich das umgekehrt machen payment = [wie jederzeit bezahlt werden kann] payment:Zeitraum = [Zusätzlich kann in der Zeit auch mit XX bezahlt werden] also payment = maestro payment:0700-2200 = cash;mastercard;dkv das bedeutet dann: * Bezahlen kann man normalerweise bar oder mit den genannten Karten * Einschraenkung: im Zeitraum von 22-7 Uhr gibt's nur einen Automaten * Der Automat nimmt nur ec-Karten an. Wer das einfacher und eindeutiger hinbekommt, melde sich bitte... http://wiki.openstreetmap.org/wiki/Key:opening_hours payment:cash = 07:00-22:00 payment:mastercard = 07:00-22:00 payment:dkv = 07:00-22:00 payment:maestro = yes (oder 24/7) Hängt auch vom Anwendungsfall ab: Wenn ich wissen möchte, mit welchen Mitteln ich dort bezahlen kann, können Deine Tags besser ausgewertet werden, wenn mich interessiert, ob ich mit *meiner* Karte bezahlen kann, dann kann mein Tagging einfacher ausgewertet werden. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm richtig getaggt?
Hallo Christopher, Zum anderen: Binde ich direkt an die Wälder oder Wohngebiete an? Diese Frage wurde schon 1'000x diskutiert, und es gibt zwei Lager: - Die Genauigkeits-Fetischisten: Für sie muss jeder noch so kleine Flecken Land, der eine andere Nutzung hat, ausgeschnitten werden und korrekt vermessen und getagged werden. Eine gemeinsame Nutzung von Nodes zwischen 'grossen Flächen' kann nicht korrekt sein, da bestimmt irgendwo ein noch nicht gemappter Streifen Grad dazwischen ist. - Die Flächen-Maler: Sie zeichnen Landuse-Flächen ein, um etwas Farbe auf die Karten zu bringen. Mit Unterstützung es Wikis (landuse=überwiegende Nutzung) nehmen sie es nicht so genau, und verschmelzen auch mal Nodes von Strassen mit den Nodes der 1 Meter neben der Strasse beginnenden landwirtschaftlichen Fläche. Je nach dem, wie genaue Daten Dir vorliegen, würde ich entweder das eine oder das andere machen.. Gruss, Thomas (Die Computer-Fetischisten erstellen Multipolygone mit Hilfe der begrenzenden Strassen und freuen sich über die Schönheit der technischen Lösung (die Fläche innerhalb dieser vier Strassen wird landwirtschaftlich genutzt). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen der Schweiz
Hallo Andreas, Ich schlage vor, national gültie Nummern ref:ch:wasauchimmer zu nennen. Mmmmh.. Österreich: ref:at:gkz Deutschland: de:amtlicher_gemeindeschluessel Frankreich: ref:INSEE Italien: nichts Alles schön gemischt.. Und habt Ihr euch die 3-Sprachigkeit überlegt? Wenn's alle verstehen sollen wechseln wir in der Schweiz normalerweise auf Englisch. ;-) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abbiegerelationen unterwegs ueberpruefen / eintragen
Hallo zusammen, Diese Woche soll man bekanntlich ein vermehrtes Augenmerk auf die Abbiege- Relationen werfen: http://wiki.openstreetmap.org/wiki/Project_of_the_week/2010/Aug_29 Doch wie überprüft man unterwegs beim Mappen am einfachsten, ob an einer Kreuzung bereits eine Relation eingetragen ist? Walking Papers: kein entsprechender Stil vorhanden OSMTracker: kein entsprechender Tile-Server vorhanden Alle Verbote fotografieren/eintragen und erst zu Hause überprüfen? Scheint mir ein bisschen aufwändig.. Also, her mit euren Ideen! ;-) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen der Schweiz
Hallo Sven und André, Am 30. August 2010 14:14 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Ach ja und wegen Schweizer Landeskoordinaten. Was bei Proj4 dabei ist taugt nicht. Folgende Parameter für proj4 sind OK: # CH 1903 / Swiss Oblique Cylindrical 9814 +proj=somerc +lat_0=46d57'08.66N +lon_0=7d26'22.50E +ellps=bessel +x_0=60 +y_0=20 +towgs84=674.374,15.056,405.346 +units=m +k_0=1 +no_defs Danke, ich habe hier bereits ein umgerechnetes shp-File, damit sollte es auch so klappen.. Wie schon beim letzten Import, möchte ich hier noch einmal Ogr2Osm vorstellen. Mit dem Python-Programm Ogr2Osm [1] werden Multipolygone automatisch aus den SHP-Flächen erstellt. Man kann zudem eine Übersetzungsdatei angeben, bei der Shape-Attribute in OSM-Tags gewandelt werden. Dies lässt sich aber auch im Nachhinein mit JOSM erledigen. Ich werde mir das Script heute Abend mal genauer anschauen. Am Aufwaendigsten wird wohl sowieso das haendische Anpassen der Relationen an die Grenzen der Nachbarlaender, wo überalls schon Grenzen bis Level 6 oder 8 vorhanden sind: http://tools.geofabrik.de/osmi/?view=boundarieslon=7lat=47zoom=9 Innerhalb der Schweiz muss noch untersucht werden, welche bereits vorhandenen Grenzen gelöscht und welche behalten werden können bzw. ob es auf Grund der neuen Lizenz nicht sowieso sinnvoll wäre, die Grenzen komplett zu importieren. (Die vorhandenen Grenzen sind entweder gleich oder weniger genau wie der neue Import.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen der Schweiz
Hallo Simon Ahem, hast du wirklich die passender Nutzungserlaubnis für OSM? Der letzter Stand von dem ich weiss, waren die Juristen der SwissTopo da immer noch dran (OSM seitiger Kontakt Thomas Ineichen). (Ich bin nur einer von mehreren, die in dieser Sache mit SwissTopo in Kontakt standen.) Inzwischen hat Markus die Sahce hier dokumentiert: http://wiki.openstreetmap.org/wiki/DE:Grenzen_der_Schweiz (Und zweitens was macht das auf talk-de?) Auf talk-de (Openstreetmap allgemeines in Deutsch[1]) ist mehr 'technische Erfahrung' vorhanden wie auf talk-ch. Gruss, Thomas [1] http://lists.openstreetmap.org/listinfo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder von Ausfahrten etc.
Hallo Jan, ich dachte jetzt gerade aktuell an bilder aus dem ausland und generell In der Schweiz gibt es http://www.autobahnen.ch/. Das Uebernehmen von Informationen von Bildern kann mMn nicht geschützt* werden, aber Du darfst gerne per Mail nachfragen. Gruss, Thomas * Insbesondere, da in der Schweiz die Huerden fuer einen urheberrechtlichen Schutz hoeher sind als in Deutschland. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen der Schweiz
Hallo zusammen, Ach ja und wegen Schweizer Landeskoordinaten. Was bei Proj4 dabei ist taugt nicht. Folgende Parameter für proj4 sind OK: # CH 1903 / Swiss Oblique Cylindrical 9814 +proj=somerc +lat_0=46d57'08.66N +lon_0=7d26'22.50E +ellps=bessel +x_0=60 +y_0=20 +towgs84=674.374,15.056,405.346 +units=m +k_0=1 +no_defs Gemeinsam mit deinem proj4-String sollte es ein relativ gutes Ergebniss liefern. Einzig die Nachbearbeitung und Löschung schon vorhandener Grenzen und Wasserflächen ist mittels dieser Methode Handarbeit. Ich hab jetzt nicht nachgeschaut, welche Bibliothek ogr2osm verwendet, aber mit dem Parameter -e 21781 konnte ich mir eine OSM-Datei erstellen, die maximal 1.5 Meter neben Grenzen liegt, welche der offi- zielle WMS-Dienst von http://geo.admin.ch/ liefert. Genauer wirds mit obiger Formel (wo/wie müsste ich die eingeben?) auch nicht, odr? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Hinweise auf Autobahnen (war: Autobahnrouting)
Hallo Michael, Wenn ja: mit welchen Tags sollte man so etwas machen? http://wiki.openstreetmap.org/wiki/Key:destination MMn kann man das ruhig auch für die 'geradeaus' weiterführende Auto- bahn verwenden. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder von Ausfahrten etc.
Hallo Simon, Thomas schreibt: * Insbesondere, da in der Schweiz die Huerden fuer einen urheberrechtlichen Schutz hoeher sind als in Deutschland. Nur ist das völlig irrelevant, da das Recht vom Land in dem die Daten/Bilder genutzt werden massgebend ist. Auch wenn's off-topic wird: Ich hätte jetzt behauptet, dass, was im Ursprungsland keinen Schutz geniesst, auch im Ausland nicht geschützt sein kann - die Berner Übereinkunft[1] sieht das aber tatsächlich anders: Art. 5 1) Die Urheber geniessen für die Werke, für die sie durch diese Übereinkunft geschützt sind, in allen Verbandsländern mit Ausnahme des Ursprungslands des Werkes die Rechte, die die einschlägigen Gesetze den inländischen Urhebern gegenwärtig gewähren oder in Zukunft gewähren werden, sowie die in dieser Übereinkunft besonders gewährten Rechte. 2) Der Genuss und die Ausübung dieser Rechte sind nicht an die Erfüllung irgendwelcher Förmlichkeiten gebunden; dieser Genuss und diese Ausübung sind unabhängig vom Bestehen des Schutzes im Ursprungsland des Werkes. Infolgedessen richten sich der Umfang des Schutzes sowie die dem Urheber zur Wahrung seiner Rechte zustehenden Rechtsbehelfe ausschliesslich nach den Rechtsvorschriften des Landes, in dem der Schutz beansprucht wird, soweit diese Übereinkunft nichts anderes bestimmt. [...] Bei meiner ersten Nachricht liess ich mich vom Meili-Urteil[2] leiten: Das Bild wurde von der BBC in England benutzt und trotzdem wurde der Fall nach Schweizer Recht beurteilt und dem Bild keine Schutz- würdigkeit zugestanden. Ich sag nur: Vor dem Richter und auf hoher See... Trotz allem bleibe ich bei meiner Grundaussage, dass die *Information* auf den Bildern der Autobahn-Tafeln nicht schützbar ist. Gruss, Thomas [1] http://www.admin.ch/ch/d/sr/i2/0.231.15.de.pdf [2] http://www.sbf.ch/fotografie-urheberrecht/beurteilte_faelle.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Name von Strassenkreuzung
Hallo Martin, Am 25. August 2010 16:13 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: - Von jeder Strasse 5 m abschneiden und mit name=* taggen würde ich zusätzlich zur area machen, aber nicht nur 5 m, sondern die komplette Länge über den Platz (sind deutlich mehr), bis zu den Schnittpunkten mit der pedestrian-Fläche (also splitten), aber nur dann, wenn die Straßen dort auch den Platznamen tragen (siehst Du evtl. nur an den Hausnummern/Adressen). Ich konnte vor Ort nirgends ein Namensschild entdecken und alle Gebäude haben Adressen der startenden/querenden Strassen.. Gäbe es Adressen mit Zweierplatz wäre eine Aufteilung und Benennung der kurzen Strassenabschnitte auch für mich ein klarer Fall.. (Ich bin mir noch nicht einmal sicher, ob die Züricher vor Ort wissen, dass diese Kreuzung einen Namen hat.) wenn Du noch weiter optimieren willst, würde ich die baulichen Trennungen mappen (also z.B: 2 oneways bei Trennung) z.B. an der Strassburgstrasse. Damit fange ich erst an, wenn wir hochauflösende Bilder der Stadt haben. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap in großer Business-Zeit ung
Hallo Andreas, Und evtl. kann man auch Usern, die nur mal schnell was eintragen wollen ein Werkzeug zur Hand geben, wie sie z.B. ihre Hausnummer oder ihren Laden in die Karte einzeichnen, ohne sich durch alle Tags und Editoren durchzuwühlen. Halt so wie es Google vorgemacht hat ;-) http://www.openaddresses.org/ (Wenn sie denn den Rückimport nach OSM mal hinkriegen..) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap in großer Business-Zeitung
Hallo Wolfgang, am Donnerstag, 26. August 2010 um 22:32 schrieb Wolfgang: Hallo, Am Donnerstag 26 August 2010 12:00:02 schrieb Willi: Am 26. August 2010 00:27 schrieb M∡rtin Koppenhoefer [dieterdre...@gmail.com] Zitat aus http://www.business-geomatics.com/online/anwendungen-a-produkte/59-anwend ungen-a-produkte/317-hobby-kartographen-erfassen-die-welt.html Die Navteq-Daten werden nach der ISO-Norm 9000 erhoben. 'Dadurch entsteht eine hohe Qualität der Daten in Bezug auf die Fahrzeugnavigation', betont Maike Krause-Traudes. Die gesamte Veröffentlichung ist einfach nur peinlich. Wer ungeprüft einem Datenbestand, egal von wem, Fehlerfreiheit unterstellt und Abweichungen eines anderen Datenbestandes dann falsch, aber folgerichtig als Fehler interpretiert, handelt unwissenschaftlich, ohne jedes ingenieurmäßige Denken, und zeigt, dass er/sie die erforderliche Qualifikation für eine berufliche Tätigkeit noch nicht erreicht hat. 6 - setzen. Das Fraunhofer IAIS hat Zugriff auf lizenzierte Navteq-Daten, und so hat Ina Ludwig in ihrer Diplomarbeit eine deutschlandweite Qualitätsuntersuchung von OSM anhand des Navteq-Datenbestands als Referenz durchgeführt. Die Untersuchung macht keine absoluten Aussagen, sondern zieht einen Vergleich zu den Straßendaten von Navteq, heißt es in dem Bericht der drei IAIS-Wissenschaftlerinnen. Das Navteq-Straßennetz sollte als kommerzielles Produkt eine hohe Qualität haben und sich als Referenzdatenbestand eignen. Wer Texte nicht komplett liest, egal von wem, und dann falsche Schlüsse zieht, ... [s.o.] :- Gruss, Thomas, ausserdem legen einem Journalisten schon mal gerne Worte in den Mund, die man so gar nie gesagt hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Name von Strassenkreuzung
Hallo zusammen, In der Strassenliste der Stadt Zürich sind einige Plätze aufgelistet, die de facto nur aus einer grossen Strassenkreuzung bestehen, so zum Beispiel der Zweierplatz: GIS Kanton Zürich: http://www.gis.zh.ch/gb/gb.asp?app=GB-BASISrn=12YKoord=0XKoord=0start=682270.157$247506.043Massstab=1000 bzw. http://tinyurl.com/ZweierplatzGIS Google Maps / Street View: http://maps.google.ch/maps?f=qsource=s_qhl=engeocode=q=Zweierplatz,+Z%C3%BCrichsll=46.362093,9.036255sspn=5.474155,9.876709ie=UTF8hq=hnear=Zweierplatz,+8004+Z%C3%BCrichll=47.373168,8.528094spn=0.002623,0.004823z=18layer=ccbll=47.373202,8.527948panoid=ezhxb3EspQOrkeGoLVtVtwcbp=12,234.09,,0,3.5 bzw. http://tinyurl.com/ZweierplatzSV OSM Karte: http://www.openstreetmap.org/?lat=47.373257lon=8.528239zoom=18layers=M OSM Way: http://www.openstreetmap.org/browse/way/72706805 Spontan fallen mir drei Tagging-Möglichkeiten ein, die alle ihre Vor- und Nachteile haben: - Fläche mit highway=pedestrian, name=* (momentane Lösung) - Kreuzungspunkt als place=locality, name=* - Von jeder Strasse 5 m abschneiden und mit name=* taggen Wie würdet ihr bei solchen Plätzen vorgehen? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1 Jahr Lähmung von OSM durch Lizenzwechs el?
Hallo Martin, Klar, einen offiziellen Button dafür gibt es nicht, man könnte allerdings (letzenendes wohl nur unverbindlich) eine Liste im Wiki machen, wo sich jeder, der nach eigenen Angaben absolut sicher die Umstellung ablehnt, mit seinem OSM-Usernamen eintragen kann. http://wiki.openstreetmap.org/wiki/Category:Users_Rejecting_ODbL und http://wiki.openstreetmap.org/wiki/Category:ODbL_Supporter Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koordinatenangaben in Verordnung
Hallo Falk, Nehmen wir mal an es ist Gauß-Krüger. In welchem Genauigkeitsbereich bewegt man sich denn so, wenn man die oben angegebenen Koordinaten zu Grunde legt (denen wohl eine Stelle fehlt)? GK-Koordinaten sind meter-genau. Da Deinen Koordinaten die letzte Stelle fehlt, beträgt die Genauigkeit +/-5 Meter. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Karte geht live
Hallo Melchior, Wie immer sind natürlich Anregungen, Kritik usw willkommen. Vielen Dank erstmal für den tollen Service! :) Da ich gerade meine erste Super-Relation (type=line) eingetragen habe: wie oft werden die Fahrplan-Daten (Popups, Bereiche zusammengehöriger Haltestellen, etc.) neu berechnet? Zudem wäre ich noch immer dafür, dass die Höhe der Karte auf ca. 80% begrenzt wird, damit auch der Abschnitt unter der Karte beachtet wird. ;-) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Hallo Colliar, Am 16.08.2010 21:44, schrieb Thomas Ineichen: Hallo fly, We sieht das eigentlich für wheelchair dann aus wenn vehicle=no gesetzt ist ? wheelchair=* wird eher für die physische Zugänglichkeit (e.g. Toiletten, Treppen, ...) genutzt. Mir ist allerdings kein Land bekannt, in dem Rollstühle von einem allg. Fahrverbot erfasst werden. Dann ist aber die Klassifizierung unter vehicle auf der access-Seite falsch und wheelchair sollte unter Besonderheiten und nicht unter vehicle=* stehen. Thou shalt not read the English Version! Auf der deutschen Seite habe ich die Aufteilung vor Längerem mal angepasst, die englische Version (physical access for wheelchair users) ist äh.. verbesserungswürdig. Ich bin mir sowieso noch nicht sicher, ob die Access-Pyramide inter- national oder länderabhängig sein soll.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad- und Wanderweg auf gleichem Weg -- wie taggen
M∡rtin Koppenhoefer schrieb: IMHO nein. Du schreibst oben: Wenn ich mich recht entsinne, ist der Weg für motorisierte Fahrzeuge gesperrt (Schild 250) aber für ^^ Anliegerverkehr frei. Es gibt keine blauen Schilder mit Fahrrad und Mensch (Schild 240). es ist rechtlich gesehen ein bicycle=no, da alle Fahrzeuge ausser Anliegern verboten sind. Ggf. könnte man argumentieren (IANAL), dass Radfahrer durch den Radweg ein Anliegen haben, ansonsten ist das rechtlich: Fahrrad schieben. Das wissen wir erst, wenn uns Holger sagt, ob da alle Fahrzeuge (Schild 250) oder 'nur' motorisierte Fahrzeuge (Schild 260) verboten sind. Ein Vertipper bei der Zahl ist allerdings wahrscheinlicher als dass ihm ein motorisierte reingerutscht ist. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Hallo fly, We sieht das eigentlich für wheelchair dann aus wenn vehicle=no gesetzt ist ? wheelchair=* wird eher für die physische Zugänglichkeit (e.g. Toiletten, Treppen, ...) genutzt. Mir ist allerdings kein Land bekannt, in dem Rollstühle von einem allg. Fahrverbot erfasst werden. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
Hallo Martin, Am 10. August 2010 14:09 schrieb NopMap ekkeh...@gmx.de: Ja, es gibt zur Zeit ein paar Stellen mit Multipoly-Problemen. Allerdings bin ich da momentan etwas ratlos, da ich die neuste Version von osm2pgsql benutze und keine Ursache in den Daten erkennen kann. hier noch ein Beispiel für nicht gerenderte Multipolygone: http://www.wanderreitkarte.de/?lon=12.828lat=42.448zoom=11 http://www.openstreetmap.org/?lat=42.448lon=12.828zoom=11layers=M Das könnte an folgendem Way liegen, der zwar die Rolle outer hat, aber nicht wirklich zu den Grenzen des Polygons gehört: http://www.openstreetmap.org/browse/way/68914479 Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: freiwillige Zustimmung ab jetzt moeglich
Hallo Heiko, Sollte der Relizenzierungsprozess Erfolg haben und eine ausreichende Masse doch zusammen kommen, kannst Du ja den erantwortlichen vorschlagen, eine Möglichkeit einzurichten zum Anklicken Ich mache nicht mehr mit, aber mit meinen Daten könnt ihr machen was ihr wollt. Das klicke ich dann an. Das kannst Du jetzt bereits machen: http://openstreetmap.org/user/terms Neue Contributor Terms bestätigen und zusätzlich PD auswählen. Fertig. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] öpnvkarte.de noch aktiv?
Hallo Jonas, den gerenderten Haeusern nach muss die Karte schon fast ein viertel Jahr alt sein. Ist die Seite eigentlich noch aktiv? Konnte weder Betreiber darauf finden, noch einen Hinweis zur Lizenz sehen. Auf der Seite einfach mal nach unten scrollen? (Du wärst nicht der Erste, der das übersieht..) Offenbar gibt's momentan grössere Probleme; vor ein paar Tagen waren beim Neu-Rendern plötzlich nur noch Nodes, aber keine Linien mehr zu sehen. Wahrscheinlich sind die April-Tiles der letzte komplette Datensatz, der Melchior auf die Schnelle zur Verfügung stand.. Mein Tipp: einfach ein, zwei Tage Geduld haben.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers wieder ausgefalle ?
Hallo Jan, ist Openlayers wieder einmal ausgefallen ?? Ja - darum empfiehlt es sich, OpenLayers.js auf dem eigenen Server zu hosten. Wer seinen Traffic etwas verkleinern möchte, der kann sich eine eigene, abgespeckte Version erstellen: http://openlayerer.appspot.com/ Einfach die Elemente anklicken, welche man benötigt und 'Generate OpenLayers.js' drücken - fertig. (Allerdings sollte man schon wissen, was man tut..) Gruss, Thomas, der das Tool auch erst heute entdeckt hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Hallo Sebastian, http://wiki.openstreetmap.org/wiki/DE:Bicycle_road Danke für die Zusammenfassung. Ein paar Anmerkungen dazu: Das aktuelle Proposal zu highway=cycleway [1] scheint sich nicht so recht durchzusetzen (2x verwendet)[2], was daran liegen mag, dass es in Mapnik nicht gerendert wird. Hier war wohl highway=cycleroad gemeint.. Die neue Seite soll die über mehrere wiki-Seiten verstreuten Informationen [3],[4] bündeln und zu einem nutzbaren und konsistenten Tagging führen. Wie gestern an anderer Stelle gesagt: drei verschiedene Seiten können - wenn man nicht aufpasst - auch zu drei verschiedenen Schemen führen. ;-) Ich habe an dieser Stelle den Ansatz verfolgt, der schon des öfteren vorgeschlagen wurde: Statt einen neuen highway Typ einzuführen, kann man den rechtlichen Status auch einfach als bicycle_road=yes kennzeichnen. Ja, ich fürchte, für einen eigenen highway-Tag ist die Fahrradstrasse einfach zu unwichtig. Zum Tagging: - bicycle=designated bedeutet *nicht*, dass keine anderen Fahrzeug- arten zugelassen wären, sondern nur, dass der Weg speziell für Fahrräder geeignet ist; vehicle=no darf also nicht weggelassen werden. - Auch bicycle=official (was theoretisch richtiger wäre) sperrt einen Weg nicht automatisch für andere Benutzer (bei Radwegen macht dies implizit das deutsche Gesetz). Trotzdem ist die Gefahr gross, dass eine Fahrradstrasse mit highway=path mit einem Radweg verwechselt würde. Zusätzliche Angaben wie 'foot=yes' wären daher von Vorteil. - Anlieger frei: mit access=destination sperrst Du den Weg für Fuss- gänger und Reiter* ohne 'destination'. Hier solltest Du vehicle= destination benutzen. - Kraftfahrzeuge frei: vehicle=no sollte für Nischen-Anwender wie Inline-Skater** und Kutscher* gesetzt werden. Gruss, Thomas .oO(mmmh, das mit designated und official ist manchmal kompli- zierter, als man denkt)Oo. * Soweit ich das sehe ist mit Pferden in der Nähe von Fahrradstrassen sowieso nicht zu rechnen.. ** Zumindest hier in der Schweiz gehören Inline-Skates, Skateboards, Kickboards, etc. zur Gruppe der 'fahrzeugähnlichen Geräte'; je nach Land (Niederlande?) ist eine Einteilung unterhalb 'vehicle' durchaus vorstellbar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag access = designated kann was bedeuten?
Hallo Tirkon, bicycle = designated ist, dürfen dort nur Fahrräder langfahren, richtig? Das bedeutet, dass der Weg für Fahrräder benutzungspflichtig ist. Es sagt nichts über andere Verkehrsteilnehmer aus. Zum Beispiel ist ein kombinierter Rad- und Fußweg auch für Fußgänger benutzungspflichtig. Inzwischen werden blau beschilderte Wege (nicht alle davon sind benutzungs- pflichtige Radwege) häufig mit bicycle=official getagged. bicycle=designated hat eher unverbindlichen Charakter, so werden z.B. auch Radrouten, die über highway=residential führen mit 'designated' gekenn- zeichnet. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag access = designated kann was bedeuten?
Hallo Tirkon, Ich stimme Dir vollkommen zu, dass das Wiki in diesem Abschnitt ziemlich diffus ist. Es bräuchte da mal einen Revisor, der in einem Bereich wohnt, wo der access in größerem Stil getaggt wird und der von daher eine guten Gesamtüberblick über dessen sinnvolle Anwendung hat. Wie beschreibt man: auch dieses (und jenes) nur dieses (und jenes) dieses (und jenes) nicht dies (und das) und jenes (und solches) nicht dies (und das) mit Ausnahme von jenem (und solchem) . Ich habe vor einiger Zeit angefangen, eine entsprechende Karte zu rendern, welche auch Vererbungen darstellt: http://wiki.openstreetmap.org/wiki/User:T-i/QA-Map Zur Zeit warte ich darauf, dass sie auf dem Toolserver weltweit gerendert wird. (Leider gibt es noch technische Probleme, welche aber bald behoben sein sollten.) Zudem könnten die wichtigsten Access-beschränkenden Verkehrsschilder mit den konkreten Taggings aufgeführt werden - auch auf die Gefahr dass dies auch schon an anderer Stelle getan wurde. So bliebe das Suchen erspart. Das macht doch die von Dir erwähnte Seite bereits?! http://wiki.openstreetmap.org/wiki/DE:Germany_roads_tagging Zu viele Wiki-Seiten mit dem gleichen Inhalt führen nur zu Widersprüchen, wenn nicht alle Seiten aktuell gehalten werden. Ich stoße da vereinzelt auf Straßen mit langen Listen z.B. von xy=yes Tags und frage mich, ob das so sein muss oder ob das nicht kürzer geht. Es stehen da ja auch nicht zehn Erlaubnisschilder. Das liegt wahrscheinlich auch an der Auswahlliste, die JOSM vorgibt. Vorlagen - Strassen - Wege - Pfad In sofern wäre es auch sinnvoll, am Anfang des Access Wikis erst einmal sämtliche möglichen Tags für Verkehrteilnehmer auf der Straße aufzuzählen, für die es eine Inklusion oder Exklusion geben kann. Ich habe in meinem Diagramm die unumstrittenen Teilnehmer hierarchisch dargestellt. Bei den anderen (moped/mofa, psv/bus/taxi, ...) gibt es leider Unterschiede von Land zu Land. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Hallo Martin, Am 25. Juli 2010 23:38 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: http://www.openstreetmap.org/?lat=50.3743lon=7.69686zoom=17layers=M Eine Strasse, die erst mehrere Meter *nach* der Auffahrt bzw. *vor* der Ausfahrt den Typ wechselt? Laut 'note' ist das Zwischenstück keine Schnellstrasse, aber dann müssten doch die Auf-/Ausfahrt im Norden sowie die Ausfahrt im Süden auch Primary sein? So jedenfalls scheint mir das Tagging unlogisch.. Schnellstraße (Kfz-straße) ist ein unabhängiges Attribut, einfach zusätzlich: motorroad=yes Die Primary ist sowohl mit 'motorroad=yes' als auch mit 'note = Dieses Teilstück ist keine Schnellstraße! Bitte nicht mehr in trunk ändern!' getagged: http://www.openstreetmap.org/browse/way/52981819 (Sehr schön ist das motorroad-Rendering mit Osmarender sichtbar: http://www.openstreetmap.org/?lat=50.37423lon=7.69717zoom=17layers=O ) ich würde in dem Fall durchgängig highway=trunk verwenden, dass highway um das Netz geht, haben wir ja mittlerweile geklärt. Eben.. solange nach der Kreuzung die ersten 50 Meter als 'trunk' gemapped sind, komme ich mit dem Fahrrad sowieso nicht auf das primary-Zwischenstück - egal ob die Primary eine Motorroad ist oder nicht. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FrOSCamp 17./18. September 2010 an der ETH Zürich
Hallo zusammen, Auf der Schweizer Mailingliste[1] planen wir gerade die Teilnahme am FrOSCamp mit einem eigenen Info-Stand. Freiwillige Helfer finde ich 'im Ausland' wohl nicht, aber vielleicht ja doch den einen oder anderen zusätzlichen Besucher.. ;) | Beim FrOSCamp handelt es sich um ein internationales zweitägiges Event, | das im September in den Räumlichkeiten der ETH Zürich stattfindet. Der | Eintritt ist frei. Eine Vorregistrierung für Besucher wird nicht | vorausgesetzt. Das Event besteht aus einer Ausstellung, Vorträgen, | Workshops und Hackfests rund um Open Source und Free Software sowie | Freien Inhalten im Allgemeinen. | | Personen und Projekte sind herzlich eingeladen ihre Arbeit zu | demonstrieren und den Besuchern die Bedeutung von FrOS klar zu | machen. Dabei kommt der Event ohne kommerzielle Aussteller (ausser bei | Snacks und Getränke) aus. Projekte sollten die Gelegenheit wahrnehmen | und deren jährliche Meetings im Rahmen dieser Veranstaltung durchführen. | Dazu bieten wir den Platz und die Infrastruktur um eure Ideen zu | verwirklichen. | | Obwohl das FrOSCamp 2010 zum Ersten mal organisiert wird, streben wir | an das Nummer eins Event auf diesem Gebiet in der Schweiz und | Süddeutschland zu werden. Natürlich sind auch Teilnehmer aus aller | Welt herzlich willkommen. | | Am Abend des ersten Veranstaltungstages wird es eine Party geben, wo | Creative Commons Bier und freie Musik nicht fehlen dürfen. Weitere Infos: http://www.froscamp.org/ Grüsse aus der Schweiz und vielleicht bis bald, Thomas [1] http://lists.openstreetmap.ch/mailman/listinfo/talk-ch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
Hejsan, ich habe ein Problem mit dem Siljan-See in Schweden; auf der schwedischen Mailingliste konnte mir keiner helfen. Es geht um den See Siljan http://www.openstreetmap.org/browse/relation/5336 Ich würde als erstes beim Outer-Weg natural=water löschen (ist ja bei der Relation selbst bereits getagged) und auch layer=-1 (wenn alles korrekt ist, ist der Layer überflüssig). Vielleicht hilft das bereits. 3) http://hikebikemap.de/?zoom=14lat=60.91006lon=14.58866layers=BT Hier verschwinden die Inseln bei bestimmten Zoom-Leveln. Bei der dieser Karte liegt es daran, dass die Tiles auf dem Toolserver kein 'Ablaufdatum' haben, d. h. man muss ein Löschen und Neu-Rendern explizit per /dirty anfordern. Ich habe das soeben bei ein paar Tiles gemacht und wie Du siehst geht die Insel nun auch bei den anderen Zoom-Levels unter.. Zu den anderen Karten kann ich leider nichts sagen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, Elemente einer Relation versehe ntlich gelöscht, wie zurückrollen
Hallo Andreas, http://wiki.openstreetmap.org/wiki/DE:JOSM/Werkzeuge#Gel.C3.B6schte_Relationen_wieder_herstellen Hmmm, so ganz verstehe ich die Anleitung nicht. Ich soll in Punkt 4. http://api.openstreetmap.org/api/0.6/relation/405648/5309248 aufrufen - aber im Browser bekomme ich eine Leere Seite und in JOSM bei Datei - Adresse herunterladen kommt eine Fehlermeldung, daß das Object nicht existiert. In http://www.openstreetmap.org/browse/relation/405648/history kann ich es aber sehen. Kann jemand weiterhelfen? Probier's mit der Version, nicht mit der Changeset-ID, dann sollte es klappen.. ;-) http://www.openstreetmap.org/api/0.6/relation/405648/11 Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Hallo Thomas, Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Geradeausfahren? Der Router sollte eigentlich nur auf no oder only achten, der Rest ist für die graphische Darstellung und die einfachere Verständlichkeit für uns Menschen. Daher überrascht es mich, dass die erste Variante mit Skobbler nicht funktionieren soll - ich vermute da eher einen Fehler in der Relation. Hast Du einen Link zur entsprechenden Auffahrt? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Guenther, Es gibt im grossen und ganzen nur zwei Moeglichkeiten: Man entwickelt was total eigenes, unabhaengig und parallel zum bestehenden Schema, oder man versucht das bestehende zu erweitern. Letzteres mag zwar Konflikte verursachen, aber letztendlich sehe ich da eine wesentlich hoehere Wahrscheinlichkeit, dass es auch angenommen wird. Chaos wird's (in einer Uebergangsphase) immer geben. Nein. Am Anfang war amenity=parking. Dann kam das Proposal für Entlang von Strassen parken. Solange das neue Konzept nicht versucht das Alte zu ersetzen muss dies auch nicht zu einem Chaos führen. Genau so wäre es bei der Einführung eines Taggings für einzelne Parkstände. naja, es bringt ja nix, wenn man das tollste Schema hat, und es nur von drei Leuten benutzt wird ;-) die alte Problematik existiert ja immer noch: getaggt wird bevorzugt, was auch gerendert wird, aber gerendert wird das was oft genug vorkommt. Inzwischen hat man übrigens herausgefunden, dass die Henne vor dem Ei da war: http://de.news.yahoo.com/34/20100715/tsc-huhn-oder-ei-forscher-finden-antwort-98fda55.html ;-) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Hallo zusammen, Das Relations-Problem ist ja inzwischen gelöst.. :) http://www.openstreetmap.org/browse/relation/530958 Was mich mehr interessiert ist die Stelle etwas nordöstlich davon: http://www.openstreetmap.org/?lat=50.3743lon=7.69686zoom=17layers=M Eine Strasse, die erst mehrere Meter *nach* der Auffahrt bzw. *vor* der Ausfahrt den Typ wechselt? Laut 'note' ist das Zwischenstück keine Schnellstrasse, aber dann müssten doch die Auf-/Ausfahrt im Norden sowie die Ausfahrt im Süden auch Primary sein? So jedenfalls scheint mir das Tagging unlogisch.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bei öff. Einrichtungen - Gebäude oder Grundstück?
Hallo Peter, wie taggt man eigentlich richtig bspw. ein Schul-Gebäude, welches ja auch auf einem Grundstück steht?? Das Gebäude oder das Grundstück?? http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool verstehe ich gar so, dass man das *Gelände* mit amenity=school name=Hogwards versieht?? Könnte man machen - aber, was ist dann mit Grundstücken, auf denen mehrere Gebäude stehen? Nebenbei bemerkt: Häufig wird das Schulhaus auf einem amenity=school-Gelände anstatt mit building=yes mit building=school getagged. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Hallo steffterra, All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplätze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? Falsche Logik. Alles, was mit amenity=parking bezeichnet wird ist (auch) ein Parkplatz, aber nicht alles was, was unter Parkplatz bekannt ist, wird als amenity=parking eingetragen. Es hat nie jemand bestritten, dass amenity=parking nicht unbedingt beste Wahl für 'grosse Parkplätze' war, aber die Wahl wurde vor langer Zeit mal so gemacht (egal ob im- oder explizit). Wenn Du im Potlatch z.B. das P-Symbol auswählst, dann steht oben drüber 'car park', was eindeutig ein 'grosser Parkplatz' ist. Bitte klärt mich mal auf, wie sich das mit der derzeitigen Philosophie hinter amenity=parking=großer Parkplatz verträgt und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key für die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. Du vermischst hier zwei Aspekte a) Parkplatz für bestimmte Gruppen vs. 'normaler' Parkplatz (wobei das Motorrad nochmals eine *ganz* andere Kategorie ist) b) einzelne Stellplätze vs. grosser Parkplatz Sowohl a) wie auch b) wollen wir irgendwie unterscheiden, wobei die Gruppen-Parkplätze immer nur als Stellplätze (ev. innerhalb eines grossen Parkplatzes) vorkommen. Ich wage übrigens zu bezweifeln dass amenity=disabled_parking kompli- zierter ist als amenity=parking, capacity=1, capacity:disabled=1. Ich habe mal spontan ein paar Leute gefragt, die nichts mit OSM am Hut haben, die mir alle sagten: klar sind das alles im deutschen Sprachgebrauch Einzel-Parkplätze, aber natürlicherweise sagt jeder Parkplatz. Wenn man auf Parkplatzsuche geht, würde man ja auch nicht ausschließlich nach einen großen Parkplatz suchen, sondern einen Einzelplatz, wo man sein Auto/Motorrad parken kann. Wenn ich Dich frage: Wo parke ich am besten, wenn ich in Berlin zum Brandenburger Tor möchte? Was wäre dann Deine Antwort? Ich kenne da einen Parkstand in der Dorotheenstrasse. Wenn dieser einzelne Platz schon besetzt ist, dann fahr halt in die Scheidemann- strasse, da ist noch ein anderer Parkstand oder doch eher Fahr ins Parkhaus beim Sony-Center, da findest Du eigentlich immer einen Platz. Ich bin trotz vorangegangener Diskussion deshalb immer noch der Meinung, dass hier irgendwas schief läuft. Da ist doch ein grundlegender Denkfehler im System. Versteht Ihr, was ich meine? Wie kann man das ausmerzen? Durch Einzeltags für alle oben aufgeführten Parkplatzarten (und allen die mir jetzt nicht einfielen), ist es doch nicht getan, oder? Die zweite, sehr viel aufwändigere Lösung wurde hier bereits vorge- schlagen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Tanzschule taggen?
Hallo steffterra, Genau, blos nicht alles, was mit Schulen und Lehren/Lernen zu tun hat unter dem Überbegriff Schule zusammenfassen. Keine Ski-Schule, Box-Schule, Sprach-Schule, Volkshochschule, etc. Das ist genauso unpraktisch wie bei Parkplätzen/Parkständen/Stellplätzen ... Einzeltags sind viel besser, weil man dann in einem großen Schulhaus mehrere Schul-Arten durch ihre Einzeltags als Nodes eintragen kann. Hast Du's endlich verstanden oder habe ich bloss die Ironie übersehen? :- Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Mann, geht mal an die frische Luft. Ich will ja hier keinen beleidigen, aber das ist der Grund, warum sich nichts bewegt. Also kein tag - alte Interpretation key dran - Interpretation nach key Wo ist das Problem? Kann man doch auch im Wiki so festhalten. Dann weiss es jeder, dass amenity=parking ohne Zusatztag/key ein großer Parkplatz ist - ist das denn so abwägig? Das Problem ist nicht die Theorie, da bin ich sogar - oh Wunder - mit Dir einer Meinung! Das Problem ist, dass die Idee nicht rückwärts-kompatibel ist. Alle Programme, welche nur die 'grossen' Parkplätze anzeigen wollen, müssen umgeschrieben werden. Genau deshalb wird nichts in die Welt gebracht. Genau wegen solcher Argumente. Natürlich hist es einfacher, etwas schnell schlecht umzusetzen, als groß aufziehen zu müssen und dafür eine geordnete Tagging-Struktur zu bekommen. Tausende von Einzeltags sind _nicht_ besser als ein Überbegriff und darin den passenden key suchen. Letzteres ist wesentlich flexibler, aber letzeres ist besser in der Einzelkämpfer-Marnier hier durchzusetzen. So ist es eben in einer Anarchie. :- Oberstes Ziel von OSM ist es nicht, ein 'abstrakt-korrektes' bzw. 'informatik-logisch korrektes' Taging-System aufzubauen, sondern es wird auch grossen Wert auf die praktische Nutzbarkeit gelegt. Wenn sich nun ein Tag in der 'falschen' Nutzungs-Art verbreitet hat, dann kann man sich überlegen, ob man für die 'neue' Nutzung nicht ein neues Tag einführen sollte. (siehe z.B. auch die leidige Diskussion um bicycle=designated) Wir würden uns nicht streiten, wenn es nicht darum ginge einen tag zu einem Überbegriff zu machen. Wenn amenity=parking schon ein überbegriff mit keys wäre, wäre es ein Kinderspiel, einfach einen neuen key einzuführen. Aber man muss ja nicht an die Zukunft denken... Lieber immer wieder neu einen Tag durchboxen. Erstens wird hier nicht durchgeboxt, sondern mit (den immer gleichen Argeumenten :- ) diskutiert. Mit boxen bringe ich nämlich niemanden dazu, 'meinen' Tag zu benutzen. Warum man bei Tags nicht nur in die Zukunft schauen kann sondern auch zurück steht weiter oben. Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter aufzuziehen, wenn man nicht darauf achten muss, wieviele unterschiedliche Tags es fürs Parken gibt. Einfach den amenity nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 neue Tags für ähnliche Dinge einzuführen. Die Frage ist aber auch, ob man überhaupt eine gesamte Datenbank aller Parkmöglichkeiten benötigt oder ob die Nachfrage von Parkhäuser und grosse Parkplätze und einzelne Parkplätze insb. Spezial-PP nicht sowieso meistens getrennt sind. Wer bespricht diese semantische Änderung auf der englischen talk Liste (bislang habe ich dort kein Wort über diese Diskussion gesehen)? Wer bespricht diese Änderung auf allen anderssprachigen Mailinglisten? Wer kümmert sich darum, das diese Änderung im Wiki *konsistent* (über alle Sprachen) geändert wird? Wer kümmert sich darum, das alle relevanten Kartenrenderer diese Änderung mitbekommen? Wer kümmert sich darum, daß Editoren ihre Presets entsprechend anpassen? ... und ich hab mit Sicherheit noch so einiges vergessen. Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und sich nicht jeder als Einzelkämpfer (der für seine Art zutaggen kämpfen würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen (mit freiem Kopf!) gesucht würde, dann könnte man das auch stark gemeinsam flächendeckend umsetzen. Wir suchen ja gerade nach einer guten Lösung. Allerdings wird es nie eine Lösung geben, die *alle* als die beste emfpinden. Irgendwo muss man ja mal anfangen, sich andere Meinungen anzuhören. Nur so langsam merke auch ich, dass hier viele eben nicht an das denken, was aus osm werden könnte, sondern, wie man am besten alles in das derzeitige Schema presst. Man merkt das es bei richtungsabhängigen Sachen eigentlich immer konfuser wird, weil tagging-ketten keine bessere Lösung als Relationen sind, weil man merkt, dass Linienbündel einen haufen Arbeit bedeuten. Blos nicht über den Tellerrand hinausdenken, es könnte Arbeit machen. Es ist einfacher im aktuellen Gedankenschema zu bleiben. Was meinst Du, warum ich hier gefragt habe und nicht einfach meine Art als *die Lösung* präsentiert habe? Wie schon mehrfach erwähnt ist parking+capacity zwar logisch aus Informatiker-Sicht, aber in OSM gibt es noch viel mehr zu beachten. Nein es fängt sogar schon bei einem Einzeltag an, dass hier keiner mehr am gleichen Ziel arbeitet, nämlich OSM zu verbessern, sondern versucht sein Einzellkämpfer-Ding innerhalb bestehender Grenzen durchzusetzen. Wenn Du die Diskussion so verstehst, dann hast Du sie nicht ver- standen. Es geht hier nicht um Durchsetzung sondern um Abwägung. Sich drum zu kümmern das die Änderungen konsistent überall
Re: [Talk-de] Behindertenparkplatz
Hallo Martin, Weil die Grösse in einer mit osm2pgsql importierten Tabelle nicht drinsteht und darum für Mapnik nicht auswertbar ist? zumindest für die Beschriftung von Flächen kann man sehr wohl nach Größe differenzieren, bist Du Dir ganz sicher mit Deiner Aussage? Hast Du ein Beispiel dafür? Das wär mir zumindest noch nirgends aufge- fallen. Die Geometrie eines Objekts ist zwar in der way-Zelle gespei- chert, aber Mapnik-Filter filtert nach diesem Wert. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Guten Tag steffterra, Ganz klares Versagen der Software in Kombination mit fehlenden keys oder eigenen Tags für unterschiedliche Parkmöglickeitsarten. Ganz klares Versagen der Entscheider dieses Tag auch für einzelne Parkplätze zu nutzen in Kombination mit fehlender Rückwärtskompatibi- lität. So oder so ähnlich könnte man das *auch* sehen.. :- Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Martin, Am 22. Juli 2010 11:56 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: zumindest für die Beschriftung von Flächen kann man sehr wohl nach Größe differenzieren, bist Du Dir ganz sicher mit Deiner Aussage? Hast Du ein Beispiel dafür? Das wär mir zumindest noch nirgends aufge- fallen. Die Geometrie eines Objekts ist zwar in der way-Zelle gespei- chert, aber Mapnik-Filter filtert nach diesem Wert. z.B. Zeile 595, 600, ff In meiner osm.xml steht da 595: Filter[tourism] = 'alpine_hut' or [amenity]='shelter'/Filter bzw. 600: Filter[amenity] = 'bank'/Filter Bei mir ist da also kein Filter über die Grösse der Fläche. Könntest Du den konkreten Code hier reinkopieren? Danke und Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Guenther, ERST braucht man ein sauberes, definiertes Datenmodell, DANN eine Anwendung die die Spezifikation entsprechend nutzt. So kann man aber nur vorgehen, wenn man etwas völlig neues erfindet, z.B. das Tagging von Parkständen entlang der Strasse. Bei amenity=parking ist das Kind aber nun mal bereits in den Brunnen gefallen.. Bei OSM hat man in den meisten Bereichen weder das eine noch das andere. So ist OSM eben. Inkl. den postitiven und negativen Auswirkungen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Wenn du diese Software bereits gebaut hättest, müsstest du sie dann natürlich umbauen, damit die Software beim Vorliegen eines solchen Zusatztags das für ihre Zwecke irrelevante Objekt auch tatsächlich ignoriert. Automatisch geht das nicht. Warum müsste ich die Software umbauen, wenn ein tag immernoch so interpretiert werden soll, wie er ist. Ich müsste lediglich eien Bedingung einfügen: wenn kein Zusatztag/Key vorhanden ist - alte Interpretation. Und wenn Key parking_area vorhadnen, gleiche interpretatioen - Parkplatz mit ways. Das *IST* bereits ein Umbauen der Funktion. Das alte Programm kann mit 'Deinem' Schema nicht mehr benutzt werden, weil es den capacity-Key nicht kennt. Der Rest des Postings wurde bereits andernorts diskutiert. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
[Zu früh auf Absenden gedrückt] Hallo Guenther, ERST braucht man ein sauberes, definiertes Datenmodell, DANN eine Anwendung die die Spezifikation entsprechend nutzt. So kann man aber nur vorgehen, wenn man etwas völlig neues erfindet, z.B. das Tagging von Parkständen entlang der Strasse. Bei amenity=parking ist das Kind aber nun mal bereits in den Brunnen gefallen.. Wenn man nun ein in der Theorie besser funktionierendes Schema entwickelt hat und einführen möchte, dann muss man es bei *allen* bis- herigen Nutzern bekannt machen, ansonsten hast Du nachher mehr Chaos wie vorher. Bei OSM hat man in den meisten Bereichen weder das eine noch das andere. So ist OSM eben. Inkl. den postitiven und negativen Auswirkungen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Eine _alte_ Software würde einen neuen Key genauso interpretieren, wie wenn er nicht da wäre, weil die alte Software den key nicht kennt - sie würde ihn ignorieren. Wo ist das Problem? Ausserdem ging es um den parking:parking_area/parking:parking_space-Key ... macht aber nix, ist ja nur ein Beispiel. alt: neu: grosser PP amenity=parking amenity=parking parking:parking_area=yes einzelner PPnicht eingetragenamenity=parking parking:parking_space=yes Die 'alte' Software sucht nach amenity=parking und interpretiert dies als 'grosser PP'. Problem nun erkannt? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Technik-HowTos
Hallo Benjamin, Hallo, die Anleitung ist prima! Zu der Aktualisierung hätte ich noch eine Frage: Ich habe nur einen kleinen Teil (in meine Fall sachsen.osm.bz2 von der geofabrik) in die Datenbank importiert. Nun will ich auch nur diesen Teil aktualisieren. Mit den minütlichen Diffs habe ich aber in einer gewissen Zeit die ganze Welt in der Datenbank. Wie stelle ich es am Besten an, nur den Teil zu aktualisieren, der in der ursprünglich importierten Grenzen liegt? Wenn Du nicht auf minuten-genaue Aktualität angewiesen bist, dann würde ich alle X Tage das Sachsen-Image neu herunterladen und mit osm2pgsql importieren (osm2psql löscht dabei die alten Daten vor dem Import). Mit einem selbst gebastelten Script für die Schweiz (wget, osm2pgsql) kostet mich das einen Doppelklick und es dauert ca. 30 Minuten. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Icon pro Relation
Hallo Sarah, Gibt es eine einfache Möglichkeit, pro Relation nur *ein* Icon anzu- zeigen? Ich würde das schon bei der Datenbankabfrage clustern. Ich kenne den genauen Aufbau der DB auf dem Toolserver nicht, aber ganz grob könnte das in SQL so aussehen: SELECT ST_Centroid(ST_Collect(geom)) FROM relations_tabelle WHERE ... GROUP BY relation_id; Logisch, ich habe mal wieder viel zu kompliziert gedacht! (Peters Posting über die Tabellen-Strukturen hat mich auf die schlechte Idee gebracht, in planet_rels nach den IDs der Members zu suchen und aus planet_line dann mit den entsprechenden LINESTRINGs ein MULTILINESTRING zu bilden.) Deine Lösung ist einiges praktischer, danke. :) Zum Nachbauen: SELECT ST_AsGeoJSON(ST_Centroid(ST_Collect(way))) AS way FROM planet_line WHERE (tags @ 'route=fitness_trail') AND way ST_SetSRID(ST_MakeBox2D( ST_Point($bbox[0], $bbox[1]), ST_Point($bbox[2], $bbox[3]) ),900913) GROUP BY osm_id; Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Hallo Frederik, bernhard zwischenbrugger wrote: Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also alle Kundendaten freigeben. Genau. Allerdings nur, wenn man die Verortung der Kunden auch öffentlich zugänglich macht. Eine Firma, die für den internen Gebrauch die Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich nicht veröffentlichen. If you publicly use any adapted version of this database, or works produced from an adapted database, you must also offer that adapted database under the ODbL. http://www.opendatacommons.org/licenses/odbl/summary/ Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Hallo Bernhard: Am 21.07.10 12:06, schrieb Thomas Ineichen: bernhard zwischenbrugger wrote: Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also alle Kundendaten freigeben. Genau. Allerdings nur, wenn man die Verortung der Kunden auch öffentlich zugänglich macht. Eine Firma, die für den internen Gebrauch die Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich nicht veröffentlichen. Da stellt sich dann aber die Frage was öffentlich ist. Ist es nicht öffentlich wenn man sich einloggen muss? Facebook würde ich jetzt mal als öffentlich bezeichen. Den Login-Bereich des Fußballclubs ist eher nicht öffentlich. Aber wo genau ist die Abgrenzung? Vielleicht muss man zuest die erste Frage nochmals etwas ausführlicher beantworten: Wenn Kunden-Datenbank und die OSM-Datanbank getrennt bleiben und die Adressen jeweils on-the-Fly dargestellt werden (also nicht in der 'privaten' Kopie der OSM-Datenbank gespeichert werden), dann muss die Kunden-Datenbank nie veröffentlicht werden, egal ob das Ergebnis öffentlich genutzt wird oder nicht. (Es handelt sich dann um eine sogenannte Sammeldatenbank.) Eine Vereinigung von Kunden- und OSM-Datenbank macht aber in den seltensten Fällen überhaupt Sinn. Öffentlich ist nach ODbL-Definition jede zur-Verfügung-Stellung an Personen, die nicht unter Deiner Kontrolle stehen. Eine Nutzung auf der internen Seite einen Sport-Vereins würde ich daher eher als 'öffentlich' sehen - aber wie oben gesagt wird der Sportverein eh keine 'abgeleitete Datenbank' erstellen. Gruss Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo M∡rtin, Am 21. Juli 2010 14:07 schrieb Tobias Knerr o...@tobias-knerr.de: amenity=parking = ein Ort, wo es nicht nur ein oder zwei, sondern ziemlich viele Stellplätze gibt. Lohnt sich definitiv, das auch in einer allgemeinen Karte zu rendern. Ist von allgemeinem Interesse, nicht nur für Spezialanwendungen. nö, 16.4.2008 bis 16.6.2009 http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparkingoldid=261073 amenity=parking: ein Ort, wo man (Autos, Motorräder, LKW) parken kann. erst danach wurde eingeführt, dass nur Parkplätze ab vernünftiger Größe eingetragen werden sollen. Vielleicht, weil vorher 'intuitiv' nur grössere Parkplätze gezeichnet wurden und man das endlich im Wiki festhalten wollte? Während ich dem für Nodes zustimme ist es für areas nicht unbedingt nötig: Wie groß das ist, ergibt sich sowieso aus der Fläche. Ob man dann für jeden Parkplatz ein P darstellen will oder nur für die großen ist dem Renderer/Router/etc überlassen. Derzeit kenne ich allerdings keinen, der es gut macht ;-) Weil die Grösse in einer mit osm2pgsql importierten Tabelle nicht drinsteht und darum für Mapnik nicht auswertbar ist? = ein Ort, wo man parken kann. Für sich genommen völlig nutzlos, weil für *jeden* praktischen Zweck eine Unterscheidung zwischen einem Einzelstellplatz und einem großen Parkplatz vorgenommen werden muss. Du meinst, wenn man mit mehr als einem Fahrzeug gleichzeitig parken will? Ich kenne aus der Praxis eher den Fall, dass man mit _einem_ Fahrzeug parken will, und da reicht normalerweise ein Stellplatz aus. Wenn ich in einer fremden Stadt nach einem Parkplatz suche, dann möchte ich in ein Parkhaus/zu einem grossen Parkplatz geleitet werden und nicht von Stellplatz zu Stellplatz. Zusammenfassend meine Sicht: Es ist sinnvoll, zwischen den folgenden 3 Fällen zu unterscheiden: a) 'grosse' Parkplätze/Parkhäuser b) Parkmöglichkeiten entlang von Strassen c) einzelner, isolierter Parkplatz (für 1, 2 Autos) bzw. Ausnahme- Gruppen innerhalb von grösseren Parkplätzen Bei gezielter Einführung von c) kann die ganze Gruppe ein gemeinsames 'amenity'-Tag erhalten, welches mit den bekannten capacity:* erweitert wird. Gruss, Thomas PS: Es gibt auch andere Fälle, bei denen 'gross' und 'klein' des selben Objekts unterschiedlich getagged werden: landuse=forest vs. natural=tree amenity=bus_station vs highway=bus_stop railway=station vs. railway=halt railway=level_crossing vss railway=crossing etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ein Icon pro Relation
Hallo zusammen, Auf meiner Jogging-Karte möchte ich gerne für tiefere Zooms pro Strecke/Relation ein Jogging-Icon anzeigen. Da die route-Relationen aber nur indirekt in der PostGIS-Datenbank gespeichert sind, ergibt dies auf der Karte eine zufällige Anzahl von Icons: http://toolserver.org/~ti/ftm/test.html?zoom=15lat=47.34045lon=8.64565layers=BFTTF Gibt es eine einfache Möglichkeit, pro Relation nur *ein* Icon anzu- zeigen? (Das 'normale' Clustering ist kein Ausweg, da auch mal zwei Strecken sehr nah beieinander sein können und ich dann lieber ein halb- überdecktes Icon hätte..) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deine Stadt an Deinem Ohr
Hallo zusammen, Heute in der Gratiszeitung 20Minuten entdeckt: http://www.20min.ch/life/beauty/story/23381393 bzw. http://fluid-forms.com/ Tolle Idee! :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Lulu-Ann, Tipp: Immer erst mal im Wiki nachlesen, was es schon gibt. Die Sachen sind da schon diskutiert. Wie Du vielleicht in meiner ersten Mail hierzu gesehen hast, habe ich die Wiki-Seite bereits gelesen. Glücklicherweise haben weder Du noch ich noch eine als 'Proposal' gekennzeichnete Wiki-Seite die Macht darüber zu entscheiden, wann eine Sache 'ausdiskutiert' ist. :) Die Frage des Renderings wird z.B. im Wiki *nicht* angesprochen. Zudem gab es hier einige Wortmeldungen, dass ein Node innerhalb eines grösseren Parkplatzes zur einfacheren Auffindung der Rolli-Parkplätze nicht schlecht wäre.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Welcher Definition? Diese sollten eine gewisse Größe aufweisen, es sollte also nicht für jede kleine Möglichkeit ein Auto abzustellen ein Parkplatz eingetragen werden. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking Bei meinem Problem geht es aber gerade um einzelne Parkplätze. Ich vermute so langsam, Du meinst: nicht eingezeichnete Plätze an denen man parken kann, kann das sein? Nein. Es ging mir immer nur um eingezeichnete Parkplätze (aka Park- stände). Was ist daran kompliziert. Kompliziert wird es dann, wenn neben einem einfachen Schema, noch weitere Tags _speziell_ für Einzelparkplätze von Dir eingeführt werden oder willst Du das gar nicht? (btw, ausser amenity=bicycle_parking gibt e derzeit keinen anderen parking-tag und das ist gut so. So muss nur dieser eine in ein amenity=parking und capacity:bicycle=yes geändert werden und gut ists. Das kann sehr einfach ein bot erledigen, sobald dass Proposal angenommen wurde: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Hier bist Du Dir inzwischen ja selber untreu geworden und möchtest amenity=bicycle_parking behalten. Warum bloss? Kompliziert ist, dass Mapnik nicht rechnen kann. Ich habe zwar inzwischen herausgefunden, dass Vergleiche einigermassen funktionieren (Filter[capacity] = [capacity:disabled]/Filter), aber sobald z.B. jemand bei beiden Werten 'unknown' hineinschreibt, springt der Filter an. z.B. capacity:disabled:yes gibts schon jetzt offiziell im wiki: http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking Es ist also längst etabliert, also führe bitte nichts neues ein. Das Rad muss nicht neu erfunden werden. Ein capacity:disabled haben meine Nodes ja auch. :- Hübsches Beispiel, wie man eine Karte unbrauchbar macht: http://www.openstreetmap.org/?lat=41.97575lon=2.81843zoom=15layers=B000FTF Wenn das alles ausgezeichnete Parkplätze sind, ist es doch nicht falsch. Das Tagging kann auch nichts dafür, dass alle drei Renderer hier nicht unter verschiedenen Parkplatzarten unterscheiden. Dass tatsächlich Behindertenparkplätze darunter sind, kann man in JOSM einfach nachschauen. Das Tagging kann sich aber überlegen, wie man die Renderer zumindes- tens unterstützen kann. Ansonsten kann Mapnik nur entweder alle an- zeigen oder keine. Und äh - wie war nochmal Deine Frage zu Beginn des Threads? Die steht glaube ich immer noch da.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Hallo ihr, highway=residental parking:lane:right=inline capacity:standard=3 capacity:disabled=1 parking:condition:right=residents parking:condition:right:residents=G bzw. highway=residental parking:lane:right=inline capacity:disabled=1 bzw. parking:lane:right:capacity:disabled=1 bzw. parking:condition:right=disabled Und wer bringt das alles den Rolli-Fahrern bei, die eigentlich nur ein paar Behinderten-Parkplätze einzeichnen möchten? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Martin, Am 18. Juli 2010 20:16 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: Eine Karte kann auch *zu* viel Information anzeigen. ja, aber das ist ein Problem des Renderers. Wichtig auf Datenseite ist, dass man die einzelnen Unterschiede festhält, so dass sie bei der Auswertung berücksichtigt werden können. D.h. man sollte z.B. schon darauf achten, dass ein Datennutzer, der ein bestimmtest (Unter-)tag nicht kennt, nicht möglicherweise eine entscheidende Änderung in der Bedeutung aufgrunddessen nicht mitbekommt (z.B. eine in Bau befindliche Straße wie eine normale Straße taggen und das Detail der Unbenutzbarkeit in einen eigenen Tag packen ist nicht sinnvoll, weil die Verwechslungsgefahr zu groß ist, s. highway=construction). Darum gehören nur-Behinderten-Parkplätze mMn auf Spezialkarten bzw. auf einen Extra-Layer. Und weil sie anders sind als 'normale' Park- plätze dürfen sie ruhig auch einen eigenen Key haben. Nujo, meine Karte versteht inzwischen beides. :- Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Das habe ich an anderer Stelle erläutert. Weil mit parking - man könnte eszumindest so definieren - KFZ-Parkplätze gemeint sind und nicht die von unmotorisierten Zweirädern. Dies wird auch dadurch gedeckelt, weil capacity:motorcycle als kex für amenity=parking im genannten Proposal vorgeschlagen wird und noch kein eigener Tag vorhanden ist. Bei bicycle ist es anders und kann dann gerne auch so bleiben ;-) Das heisst, Du ziehst Deine Inkonsequenz-Linie einfach an einem anderen Ort wie ich. Kann ich mit leben. ;-) Hübsches Beispiel, wie man eine Karte unbrauchbar macht: http://www.openstreetmap.org/?lat=41.97575lon=2.81843zoom=15layers=B000FTF Wenn das alles ausgezeichnete Parkplätze sind, ist es doch nicht falsch. Das Tagging kann auch nichts dafür, dass alle drei Renderer hier nicht unter verschiedenen Parkplatzarten unterscheiden. Dass tatsächlich Behindertenparkplätze darunter sind, kann man in JOSM einfach nachschauen. Das Tagging kann sich aber überlegen, wie man die Renderer zumindes- tens unterstützen kann. Ansonsten kann Mapnik nur entweder alle an- zeigen oder keine. Richtig, und deshalb zerbrechen wir uns ja den Kopf, ob z.b. das Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces nicht toll und ausreichend wäre. Und die Parkstände sind bereits in Jetzt wo ich das Proposal nochmals anschaue fällt mir auf: Eigentlich soll capacity=* verbannt werden. D. h. Mapnik könnte/müsste danach auf capacity:standard filtern, um 'normale' Parkplätze anzu- zeigen. (Übrigens auch ein Hinweis darauf, dass ein 'amenity=parking' eben ein Auto-Parkplatz ist/war.) diesem Proposal untergebracht: http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane , das alle Features bietet, was eine Parkstand-Tagging bietet, um es z.B. für eine Navi zu ermöglichen, alle Anwohnerparkplätze bei der Suche nicht zu berücksichtigen - nur so als Beispiel. Viele 'meiner' Rolli-Einzel-Parkplätze sind übrigens nicht mal Park- stände, wie ich heute bemerkt habe. Häufig stehen sie total isoliert (mind. 10 Meter bis zum nächsten anderen Parkfeld.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo Jens, Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. Wozu noch eine Relation? Die wird nie vollständig sein, hat extra Pflegeaufwand und keinen Mehrwert. Solange man via XAPI nur nach einem einzelnen Key und rechteckigen bounding-boxen filtern kann, solange wird es auch Leute geben, die Relationen als Filter 'missbrauchen'.. (Ja, ich gehöre mit zu diesen Leuten. Zumal die Grenzen häufig eh fliessend sind.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Sollte jemand vielleicht noch auf deutsch übersetzen... Freue mich auf Deine Übersetzung. Leider ist mien englisch nicht s gut, dass ich das adäquat könnte. Lieber Wikipedia-Benutzer, wahrscheinlich hast Du Dich daran gewöhnt, dass jeder Artikel in der Wikipedia zu mindestens einer Kategorie gehört. Sobald Du einen Artikel ohne Kategorie erstellst, wird er entweder sofort als Lösch- kandidat markiert oder einer Kategorie zugeordnet. Es gibt Leute, die den ganzen Tag nichts anderes tun als Artikeln Kategorien zuzuweisen. Relationen in OSM sind *keine* Kategorien. Sie sind dazu da, um eine enge Verbindung (meistens lokal) zwischen Objekten herzustellen; z.B. 'dieser Eingang führt zu dieser U-Bahn-Station' oder 'Du darfst von dieser Strasse nicht auf jene Strasse abbiegen'. Sie werden auch benutzt, um zusammengehörige Strassenabschnitte zu gruppieren [Anm: Sagen wir nicht andernorts, Relationen für Strassen seien unnötig?] Allerdings werden Relationen nicht benutzt, um lose Gruppen von irgendwie verbundenen Objekten zu sammeln. Es gibt keine Relation Fusswege in Westangola oder Seen in Schottland. Als Wikipedianer hast Du vielleicht das Bedürfnis, für jedes Objekt welches Du anfasst eine passende Relation zu finden - bitte widerstehe diesem Drang. Unsere Datenbank ist eine räumliche Datenbank; dies bedeutet, dass die Datenbank 'weiss', wo ein Objekt liegt. Wenn Du alle Fusswege in Westangola anzeigen möchtest, dann kannst Du einfach alle Fusswege innerhalb der Grenzen von Westangola anfordern, und die Sammlung Fusswege in Westangola wird in dem Moment automatisch erstellt. Jeder, der einen Fussweg in Westangola der Datenbank hinzufügt muss nur sicherstellen, dass der Weg korrekt getagged und am richtigen Ort ist - der Fakt, dass der Weg in Westangola ist, muss nicht zusätzlich angegeben werden. Daher, nochmals: Bitte keine Relation Fusswege in Westangola. Doch was ist mit Gruppen wie Geldautomaten der HSBC-Bank? Auch hier ist eine Relation meistens unnötig: Wenn die Geldautomaten mit einem Tag wie operator=HSBC versehen werden, dann kann jeder alle HSBC- Geldautomaten in der Datenbank abrufen; es wird keine Relation dafür benötigt. (Eine Relation macht bloss das Editieren komplizierter und fehleranfälliger.) Gruppen-Relationen machen nur sinn, wenn die Gruppierung nicht geographisch (wie oben beschrieben) oder exklusiv (wie das HSBC-Beispiel; es ist unwahrscheinlich, dass ein Geldautomat von zwei verschiedenen Banken betrieben wird) ist. Ein gutes Beispiel für eine sinnvolle Gruppierung ist die Route- Relation, bei der mehrere Way-Elemente verbunden werden, um eine Rad- oder Wanderstrecke abzubilden. Ein einzelner Weg kann in mehreren Routen enthalten sein und daher kann der Weg nicht einfach mit route=xxx getagged werden. Vielen Dank für Dein Verständnis, Diejenigen, welche Relationen erfunden haben [Dies ist nur eine Übersetzung und nicht unbedingt meine eigene Meinung.] Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Behindertenparkplatz
Hallo zusammen, Ich bastle zur Zeit an einer Karte für Rollstuhlfahrer. Nun gibt es in Städten häufig einzelne Parkplätze, auf welchen nur Behinderte parken dürfen. http://wiki.openstreetmap.org/wiki/File:Behindertenparkplatz_Stampfenbach.jpg Wie sollen diese Parkplätze getagged werden? Gegen amenity=parking capacity=1 capacity:disabled=1 sprechen meiner Meinung nach vorallem zwei Dinge: - Häufig stehen diese Parkplätze einzeln, z.B. direkt neben einem Eingang. Laut Wiki sollen mit amenity=parking aber nur grössere Parkplätze gekennzeichnet werden und nicht einzelne. - Auch wenn es nirgends explizit festgehalten ist, so verstehen sowohl die Renderer als auch die Router unter 'amenity=parking' einen Park- platz für 'normale' Autos. Ein Parkplatz für Fahrräder wird daher auch nicht mit als 'parking' mit 'capacity:bicycle=*' getagged sondern als 'amenity=bicycle_parking'. Mein Ziel ist es aber nicht, dass die Karte mit P-Symbolen zuge- pflastert weil die Berechnung ob es sich um einen reinen Behinderten- Parkplatz handelt zu kompliziert ist. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 ? (Natürlich kann und soll man bei einem grossen Parkplatz/-haus weiterhin ein capacity:disabled setzen!) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Es ist ja nicht disabled, sondern für Behinderte. Das ist ja jetzt bereits geklärt. Also was spricht gegen amenity=parking capacity:total=15 capacity:handicap=1 capacity:all=10 capacity:women=2 capacity:family=5 (Anmerkung: gegen ein capacity:normal wehre ich mich, weil das implizieren würde, dass handicap und family, etc. Nicht normal wären ;-) Nichts, solange es sich wie in deinem Beispiel um einen grossen Parkplatz handelt. Aber wie ich geschrieben habe, geht es mir um *einzelne* Parkplätze. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Dietmar, Thomas Ineichen schrieb am: Sonntag, 18. Juli 2010 17:21 Ich bastle zur Zeit an einer Karte für Rollstuhlfahrer. Nun gibt es in Hast Du dazu mehr Infos? Ich integriere aktuell in Augsburg viele Informationen hierfür [1] und wäre an einer gemeinsamen Karte interessiert, habe auch mit Osmarender Renderdateien begonnen. Ein Link folgt gleich per PM, da die Karte noch zu sehr im Beta- Stadium ist.. Mein Ziel ist es aber nicht, dass die Karte mit P-Symbolen zuge- pflastert weil die Berechnung ob es sich um einen reinen Behinderten- Parkplatz handelt zu kompliziert ist. Die Berechnung ist total einfach und mich juckt es nicht, ob die dann in den Standardkarten zu oft vorkommen (wird kaum passieren). Wir erfassen nicht für die Renderer, üblicher Spruch dazu ;) Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* für nur-Behinderten-Parkplätze benutzen möchte, ändert man die Bedeutung des Tags. Im Gegensatz dazu ist 'capacity:disabled=*' bei einem grossen Parkplatz eine *Erweiterung* des Tags. (Das ist so ähnlich wie bei der Diskussion ob eine Fahrschule auch als 'amenity=school' getagged werden soll.) Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. Das sollte auch weiterhin so bleiben. Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch verstanden: http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- blitzen, wenn dort der normale Autofahrer gar nicht parken darf. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. *Falls* man die Bedeutung von 'parking' ändert. Der einzige Grund ist das Rendern in normalen Karten. Wenn Du das nicht möchtest, erstell ein entsprechendes Ticket beim Renderer-System. Die Darstellung auf Karten und das Routing. Mit anderen Worten: die Hauptnutzungen von OSM. Wenn das mal kein Grund ist.. Oder besser: erstelle ein Ticket, damit die Rolli-Parkplätze mit extra Symbolen versehen werden. Ich habe entsprechende verfügbar, die ein normales P-Icon beinhalten mit dem Rolli-Symbol zusätzlich rechts davon. Eine Karte kann auch *zu* viel Information anzeigen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Guenther, Am Sonntag 18 Juli 2010, 20:16:29 schrieb Thomas Ineichen: Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* für nur-Behinderten-Parkplätze benutzen möchte, ändert man die Bedeutung des Tags. Und w aendert man hier die Bedeutung? Sind Behindertenparkplaetze etwa keine Parkplaetze? Nicht im bisher genutzen Sinne von amenity=parking. Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. Das sollte auch weiterhin so bleiben. Ich hab als Autofahrer noch nie einen Node mit 'amenity=parking' gesehen. Dafuer benutze ich eine Software, die mir das so anzeigt, wie ich es brauche... Dann halt als Render-Stylesheet-Ersteller, als Routing-Algorythmus- Ersteller, als ... Fakt ist: Benutze ich amenity=parking für einzelne Behindertenparkplätze, zwinge ich anderen Arbeit auf, damit sie die Daten wieder so nutzen können wie vorher. Benutze ich amenity=disabled_parking müssen sich nur diejenigen bemühen, welche 'meine' Daten nutzen möchten. Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch verstanden: http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Und was willst du uns damit sagen?!? Dass wir sehr sehr wohl *alle* für Renderer taggen. Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- blitzen, wenn dort der normale Autofahrer gar nicht parken darf. dann solltest du deinen Renderer anpassen ;-) Abgesehen davon, dass *ich* für *meinen* Renderer alles anpassen kann: Wenn ein Tagging dazu führt, dass die Daten auf *allen* anderen Renderern zu einem neuen, ungewollten Ergebnis führen, dann darf man sich ruhig überlegen, ob man vielleicht nicht doch sein Taggin-Schema ändern sollte.. @Kompliziertheit: PostgreSQL enthält (soweit ich weiss) keine IsNumeric-Funktion. Da die OSM-Daten in der Tabelle aber als String gespeichert sind, braucht es einiges an Preprocessing, um danach mit Zellenwerten mathematische Funktionen durchführen zu können (capacity - capacity:disabled = 0). Es kann also nicht 'mal eben' das Stylesheet angepasst werden, um zwischen Behinderten- und Nichtbehinderten-Parkplätzen unterschieden werden. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Guten Tag Guenther Meyer, Nicht im bisher genutzen Sinne von amenity=parking. Das mag sein, aber es widerspricht auch nicht der Definition. Welcher Definition? Diese sollten eine gewisse Größe aufweisen, es sollte also nicht für jede kleine Möglichkeit ein Auto abzustellen ein Parkplatz eingetragen werden. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking Bei meinem Problem geht es aber gerade um einzelne Parkplätze. Wenn ein Tagging dazu führt, dass die Daten auf *allen* anderen Renderern zu einem neuen, ungewollten Ergebnis führen, dann darf man sich ruhig überlegen, ob man vielleicht nicht doch sein Taggin-Schema ändern sollte.. nochmal: das bestehende Schema enthaelt alles Notwendige und ist gut dokumentiert. Wenn ein Renderer damit nicht zurechtkommt, ist das erst mal sein Problem. Nein. Wer möchte, dass sein Schema benutzt wird, der sollte sich auch Gedanken über die technische Umsetzung machen. Z.B. den Kompliziert- heits-Aspekt, den Du nicht zitiert hast. Hübsches Beispiel, wie man eine Karte unbrauchbar macht: http://www.openstreetmap.org/?lat=41.97575lon=2.81843zoom=15layers=B000FTF Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
