date:20120723

Hallo Frederik

Am 24. Juli 2012 00:03 habe ich in meiner Antwort an Roland nochmals
darauf hingewiesen, dass ich einen erkennbaren Identifikator meine,
der für alle für das externe Projekt relevanten OSM Objekte gilt und
auch für solche funktioniert, die keine "besonderen Merkmale" haben.
Daher mein Vorschlag einer Projekt-ID (z.B. schlafbank_id=...), was in
Richtung "Linked Data" geht. Diese Projekt-ID/LinkedData-ID ist
eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen
Projekt) permanent.

In diesem Sinne gibt die externe Datenbank (die ähnlich deinem
Vorschlag gemeint ist) etwas zurück für den minimalen "Bloat" den OSM
wegen der Projekt-ID/LinkedData-ID tragen muss.

Was ich bei deinem Vorschlag einer externen Datenbank noch etwas
konkretisieren möchte ist folgendes:
* Wie geht man hier mit OSM Objekten um, auf die kein "fuzzy link"
definiert werden kann (wie z.B. Sitzbänke)?
* Du sprichst davon, dass jedermann "stored queries" auf "fuzzy links"
(im Sinne Tim Alders query-to-map) anlegen kann: An welche
Query-Syntax hast du gedacht?
* Wieso sollten solche "queries/fuzzy links" nicht gerade von den
Betreibern der externen Datenbank in OSM eingetragen werden?
* Bisher haben wir von externen Datenbanken gesprochen - also
Mehrzahl: Gehört so eine "externe Datenbank" nicht eigentlich zur OSM
Infrastruktur?

LG, Stefan


Am 22. Juli 2012 22:58 schrieb Frederik Ramm :
> Hallo,
>
>ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf
> die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten
> bei OSM einschraenkt.
>
> Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte,
> seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und
> daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte
> das niemanden stoeren.
>
> Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte
> "umnumeriert", um nicht mehr genutzte "Luecken" wiederzuverwenden, sollte
> das keine Probleme verursachen.
>
> Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu
> einfuegt, sollte niemand davon etwas merken.
>
> Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde
> zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das
> Leben schwerer zu machen -> m.E. keine gute Idee.
>
> UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der
> Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper soll
> sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X ist, und
> wenn das Restaurant umzieht auf die andere Strassenseite, dann loescht er
> das und legt es neu an, oder er schiebt es rueber, ganz wie es gerade am
> geeignetsten erscheint.
>
> Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens
> nie schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID
> fuer die ganze "Bachstrasse", oder eine fuer jeden Teil-Way? Wenn ich ein
> denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem
> Way eine UUID, und spaeter zieht das Restaurant um auf die andere
> Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss
> (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in
> einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs
> pro Objekt, eine fuer jeden Aspekt...
>
>
>> Laut Overpass's Permanent ID könnte die Lösung eine "eindeutige
>> Eigenschaft" des Objekts sein, typischerweise eine Kombination von
>> Tags. Als Beispiel wird eine Relation mit den Tags "network=BAB" und
>> "ref=A 516" herangezogen. Ich finde den Vorschlag gut - man muss sich
>> aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem
>> der offenbar "unvermeidbaren menschlich- und technischen
>> Unzulänglichkeiten" nicht löst.
>
>
> Ich halte das fuer die beste Loesung, die wir haben, weil hier derjenige,
> der den Link setzt, entscheiden muss, was ihm wichtig ist, und die Mapper
> sich nicht damit herumschlagen muessen.
>
> Das Problem der "unvermeidbaren Unzulaenglichkeiten" wird dadurch nicht
> geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der
> anderen Strassenseite neu zeichne, wird das immer noch gefunden.
>
>
>> Eine OSM-externe Datenbank vergibt einen eigenen und für sie
>> eindeutigen ID-Tag in OSM, die "nicht-sprechende" Identifikatorwerte
>> erhalten, z.B. "unserprojekt:id=10001" oder "unserprojekt_id=10001".
>
>
> Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme wie
> das UUID-Konzept.
>
> Was aber eine gute Idee waere:
>
> Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit
> und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente
> Schluessel - seien das UUIDs oder Nummern oder sonstwas. Zu OSM hin benutzt
> diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland
> erfunden wurde, sondern ursrpue

[Talk-de] Editordiskusion (war: Re: Off. Re: Zurueck in die Steinzeit)

2012-07-23 Diskussionsfäden Michael Kugelmann


Am 21.07.2012 12:19, schrieb buedner:
Deinen Stolz, dass es Dir gelungen ist, Dich in den coolen Profieditor 
JOSM einzuarbeiten, kann ich durchaus verstehen.
Da ist nichts mit Stolz! Und zum 1000sten mal: JOSM ist nicht 
kompliziert! Im Gegenteil: ich finde Potlatch so kompliziert und 
Bedienungs-Fehleranfällig, dass ich selbst für Kleinigkeiten JOSM nutze. 
Potlatch ist alles andere als selbsterklärend, ich komme damit nicht 
wirklich gut klar.


Ich möchte aber zu bedenken geben, dass für jemanden, der nur 
OSM-Daten bearbeiten möchte, Potlatch ein hervorragendes Werkzeug ist.
Ich nutze JOSM auch nur um OSM-Daten zu bearbeiten. Wozu soll ich JOSM 
sonst benutzen? Wir reden nicht über QGIS oder sonstigen klassische 
GIS-Software sondern über JOSM, den Java-OSM-Editor.


Der allergrößte Teil der Editierarbeiten ist damit ohne große 
Einarbeitungszeit effizient zu erledigen, übrigens auch für den Profi.
Auch mit JOSM lassen sich ohne großen Aufwand und ohne große 
Einarbeitung sehr effizient Editierarbeiten zu erledigen, für den Profi 
aber auch sehr wohl für den Anfänger. M.E. sogar effizienter als in 
Potlatch.


Ich empfinde daher die leichte Überheblichkeit, die hier gelegentlich 
gegenüber Potlatch-Nutzern zum Ausdruck kommt, als etwas peinlich.
Da ist nichts mit Überheblichkeit. Meine Abneigung gegenüber Potlatch 
hat andere Gründe: diese Liegen in seiner Vergangenheit und seinen 
grundsätzlichen Schwächen.
* früher war jeder Edit "live". Immerhin hat man jetzt die Möglichkeit 
(aber AFAIK leider nicht den Zwang! [1]) die Änderungen erst am Ende zu 
speichern. Bei JOSM muss ich am Ende immer bewusst hochladen, das ist 
immer die Chance für einen "Notaus" (= "verwerfen der Änderungen" wenn 
ich mir nicht sicher bin ob ich gröbere Fehler gemacht habe).
* in JOSM kann ich beliebig rumspielen, da passiert nichts. Ich denke 
dass vielen "Anfängern" gar nicht bewusst war, dass sie mit dem 
vereintlichen Anfängertool Potlatch in einer Live-Datenbank agieren und 
somit beim Ausprobieren sofort Schaden anrichten...
* Potlatch hat bis vor kurzem nicht alle Daten angezeigt, welche in der 
Datenbank sind (ich weiss jetzt nicht mehr was er in der Anzeige 
unterschlagen hat). Ich weiss auch nicht ob das zwischenzeitlich gefixt 
ist. So etwas geht für mich gar nicht.
* Einige Potlatch-Versionen habe IIRC mehr oder weniger alle Objekte im 
Fenster angefasst, auch wenn sie nicht verändert worden sind. Auch 
dadurch sind in der Lizenzumstellung Problem entstanden!
* Potlatch kann nur die Daten bearbeiten, welche auf dem Server sind. 
Wenn ich meine GPS-Tracks aber aus [welchen Gründen auch immer] nicht 
hochladen will, kann ich sie in Potlatch nicht verwenden
* Kann ich für Fotomapping Fotos in großer Zahl verwenden welche bei mir 
auf der Platte liegen und am Aufnahmeort im Editor angezeigt werden? Ich 
befürchte nicht.
* Die Performance von Potlatch war in der Vergangenheit nervig (bis 
immer der Hintergrund neu gezeichnet wurde), vielleicht ist das 
zwischenzeitlich besser. UNd bei einer dünnen Internetverbindung ist das 
noch grausamer.
* Welche Hintergründe kann ich außer Bing haben? Ich habe teilweise sehr 
unterschiedliche und mehr oder weniger "exotische" Wünsche für 
Hintergründe (z.B. für Spanien oder Bayern2m)

* ... [ich könnte weitere für mich gültige Gründe aufzählen]

Sicher ist auch JOSM nicht perfekt. Aber m.E. ist JOSM im direkten 
Vergleich das "wesentlich kleinere Übel".



Grüße,
Michael.

zu [1]: man korrigiere mich bitte, wenn das zwischenzeitlich geändert wurde


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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Roland

Am 23. Juli 2012 22:47 schrieb Roland Olbricht :
> Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto
> und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich
> (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als
> url=... oder website=... ein.
>
> Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine
> Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck
> des Tags ohne Recherche erkennbar ist.
>
> Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit
> für Suchmaschinen und macht gezielt Werbung für Euer Projekt.

Genau in die Richtung geht auch mein Vorschlag, denn die URL (url=...
oder website=...) wird damit zu einem Identifikator im Sinne meiner
Projekt-ID. Ich würde statt BasisURL+UUID aber nicht die UUID nehmen -
die ist mir zu lang - sondern einen kürzeren Identifikator, den ich
innerhalb meines Projekts eindeutig und permanent halte.

Das Problem ist wieder, dass nur wenige Sitzbänke Sehenswürdigkeiten
sind und auch nicht alle bebildert sind, so dass man eine URL oder
sonst etwas identifizierendes dran hängen kann.

Was es braucht, ist einen erkennbaren Identifikator, der für alle für
das externe Projekt relevanten OSM Objekte gilt. Daher mein Vorschlag
einer Projekt-ID (z.B. schlafbank_id=...).

Das geht in Richtung "Linked Data", daher spreche ich von jetzt an
alternativ von "Projekt-ID/Linked Data ID". Die Projekt-ID ist
eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen
Projekt) permanent.

Frederik sprach in [1], dass UUID "database bloat" seien; das kann ich
nachvollziehen. Das gilt aber für "Projekt-ID/Linked Data ID" nur
bedingt, denn ein solches Projekt (bzw. externe Datenbank) gibt OSM
etwas zurück für den minimalen "Ballast" den OSM tragen muss.

LG, Stefan

[1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050


Am 23. Juli 2012 22:47 schrieb Roland Olbricht :
> Hallo Manuel,
>
>> Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
>> gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
>> als kleine "Pinnadeln" gezeigt werden. Beim Anklicken der "Pinnadel" geht
>> ein Popup mit kurzem Text und einem Foto auf.
>
> Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto
> und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich
> (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als
> url=... oder website=... ein.
>
> Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine
> Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck
> des Tags ohne Recherche erkennbar ist.
>
> Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit
> für Suchmaschinen und macht gezielt Werbung für Euer Projekt.
>
> Viele Grüße,
>
> Roland
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] LKW Mautinformationen


Hallo Frederik,

meiner Meinung nach ist die Maut eine Eigenschaft der Straße und sollte 
daher auch an der Straße getaggt werden und nicht an einer 
Routenrelation. Für eine Auswertung wäre es auch deutlich einfacher, 
wenn die Wege (in irgendeiner Form) entsprechend getaggt sind. Bei 
anderen Eigenschaften eines Weges erfassen wir ja auch nicht Start- und 
Endpunkt der Eigenschaft, sondern geben dem Weg diese Eigenschaft. Ich 
sehe jetzt erstmal keinen Grund hiervon abzuweichen.


Henning


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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Henning

Am 23. Juli 2012 18:45 schrieb aighes :
> Am 23.07.2012 17:41, schrieb Stefan Keller:
>> Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
>> Gefahr grösser als mit der UUID, dass das Projekt das Objekt
>> "verliert" (da es einer gelöscht und mit denselben Tags neu erstellt
>> hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
>> überprüfen. Daher die UUID, bzw. die Projekt-ID
>
> Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?

Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli
2012 13:34 an Georg.
Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine
Herausforderung zu sein, so einen Node zu verschieben und die ID
beizubehalten.
Siehe auch Frederiks Antwort vom vergangenen August dazu:
http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050

>>> Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
>>> frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen
>>> BBox.
>>
>> Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
>> wurde, dann ist es weg, ausserhalb der BBOX.
>
> Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht
> mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte
> dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen.

Es gibt etliche Gebiete, die ab Orthofotos abdigitalisiert wurden und
die um mehrere Meter (bis zu 30!) falsch sind, weil die Orthofotos
falsch waren.
Da steht man mit BBox sprichwörtlich im Schilf.

LG, Stefan


Am 23. Juli 2012 18:45 schrieb aighes :
> Am 23.07.2012 17:41, schrieb Stefan Keller:
>> Am 23. Juli 2012 13:16 schrieb aighes :
>>
>> Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
>> Gefahr grösser als mit der UUID, dass das Projekt das Objekt
>> "verliert" (da es einer gelöscht und mit denselben Tags neu erstellt
>> hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
>> überprüfen. Daher die UUID, bzw. die Projekt-ID
>
> Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?
>
>
>>> Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
>>> frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen
>>> BBox.
>>
>> Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
>> wurde, dann ist es weg, ausserhalb der BBOX.
>
> Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht
> mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte
> dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen.
>
> Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, wäre
> es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man will also
> wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden kopieren der
> UUID merkt man davon leider nicht viel.
>
>
> Henning
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Pascal Neis


Hi,

Frederik Ramm schrieb:
In Eurer Auswertung werdet ihr *sowieso* Heuristiken brauchen, die 
entscheiden, was zu tun ist, wenn z.B. 100m Strecke unterwegs irgendwo 
als mautfrei getaggt sind.


warum braucht man Heuristiken wenn z.B. das Ziel ist zu erfahren
wie viele KM meiner Route über mautpflichtige Straßen geht?

Zugleich faende ich die Idee, *saemtliche* Autobahnen in Deutschland mit 
toll:hgv=yes zu versehen, auch etwas problematisch.


dem stimme ich zu, ist irgendwie nicht glücklich.

Vielleicht wirklich an die Relationen gehen, da muss man weniger aendern. 

> Wenn eine Autobahn durchgehend mautpflichtig ist, koennte ja ein Tag
> an der Relation reichen.

Mhm, meinst du damit ein Relation für alle (nicht-)mautpflichtigen
Autobahnen zu erstellen, oder vorhandene Relationen der Autobahnen
um ein Tag zu erweitern? Bei letzterer Variante werden dann aber
Probleme auftreten wenn nur ein kleiner Teil der Autobahn mautpflichtig
sind ... :-/ oder habe ich dich hier falsch verstanden?

viele gruesse
pascal

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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

Hallo Frederik,

besten Dank auch aus Italien.

Ist genau das, was wir jetzt brauchen.

Volker




2012/7/23 Frederik Ramm 

> Hi,
>
>   auf
>
> http://tools.geofabrik.de/**osmi/?view=redactionbot&lon=7.**
> 84268&lat=48.78466&zoom=5
>
> gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot
> passiert ist:
>
> ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten
> Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen!
>
> ORANGE - Sachen, die der Bot geaendert hat.
>
> GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders
> nochmal angefasst wurden.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> __**_
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Roland Olbricht

Hallo Manuel,

> Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
> gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
> als kleine "Pinnadeln" gezeigt werden. Beim Anklicken der "Pinnadel" geht
> ein Popup mit kurzem Text und einem Foto auf.

Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto 
und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich 
(z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als 
url=... oder website=... ein.

Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine 
Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck 
des Tags ohne Recherche erkennbar ist.

Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit 
für Suchmaschinen und macht gezielt Werbung für Euer Projekt.

Viele Grüße,

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Tobias Knerr

Am 23.07.2012 22:11, schrieb fly:
> Bitte verwendet besser verständliche Tags. Mit N2 bzw N3 kann man nicht
> viel anfangen und erschließen lassen sich solche Abkürzungen auch nicht.

Wenn es einen gleichbedeutenden verständlicheren Begriff gäbe, fände ich
das auch besser. Aber hast du einen Vorschlag?

>>> Am 23.07.2012 18:27, schrieb Toni Erdmann:
 hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen.
 Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann
 Toll zahlen muss.

Dieses Problem lösen wir notfalls, wenn es eintritt. Derzeit haben wir
auch für andere Begriffe und Kürzel wie "hgv" keinen Geltungsbereich
angegeben. Warum jetzt damit anfangen?

>>> Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie
>>> toll:hgv:(weight>12)=yes
> 
> Finde ich schon verständlicher.

Es gab da kürzlich eine Diskussion und Wiki-Voting dazu. Resultat:
Sonderzeichen und variable Bedingungen im Key sind bei vielen Mappern
und Entwicklern nicht erwünscht. Es macht wirklich keinen Sinn, das
jetzt schon wieder ins Spiel zu bringen, denn seit dem letzten Mal hat
sich an den Argumenten nichts geändert.

Gruß,
Tobias

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

Re: [Talk-de] LKW Mautinformationen


Hi,

On 23.07.2012 17:24, Michael Herbold wrote:

Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu
taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück
in Deutschland den Tag erhalten würde.


Sicher gibt es andere Loesungen.

Erst einmal weiss ich nicht, ob der von Euch eingeschlagene Weg wirklich 
gut ist. Ob irgendwas mautpflichtig ist oder nicht, ist ja nicht sowas 
wie ein Tempolimit, dass sich alle Naslang aendert. Daher scheint es mir 
keine so gute Idee zu sein, das Vorhandensein oder Nichtvorhandensein 
einer Mautpflicht an jeden einzelnen Way dranzupappen.


In Eurer Auswertung werdet ihr *sowieso* Heuristiken brauchen, die 
entscheiden, was zu tun ist, wenn z.B. 100m Strecke unterwegs irgendwo 
als mautfrei getaggt sind.


Wenn man aber diese Heuristik mal hat, kann man dann nicht evtl. and die 
Auf-/Abfahrten irgendwie einen "Mautpunkt" setzen oder sowas, und wenn 
die Route da vorbeifuehrt, geht der Zaehler los oder so? Oder vielleicht 
etwas mit den Relationen machen?


Euer Ja/Nein-Gemisch finde ich nicht gut ueberlegt:

"Eine Autobahn kostet Maut, wenn sie in Deutschland ist und nicht 
explizit als mautfrei getaggt ist, oder wenn sie in einem anderen Land 
ist und explizit als mautpflichtig getaggt ist. Eine Bundesstrasse 
kostet immer dann Maut, wenn sie explizit als mautpflichtig getaggt ist. 
Eine niederrangige Strasse kostet nie Maut, wenn sie in Deutschland ist, 
egal wie sie getaggt ist..."


Da blickt doch keiner mehr durch. Wenn es Euch aber Ernst ist damit, OSM 
einen Nutzen zu stiften, dann muss Euer Konzept auch von jedem gut 
auswertbar sein und nicht nur von Eurer Spezialheuristik (ausser 
natuerlich die wird Open Source).


Zugleich faende ich die Idee, *saemtliche* Autobahnen in Deutschland mit 
toll:hgv=yes zu versehen, auch etwas problematisch. Vielleicht wirklich 
an die Relationen gehen, da muss man weniger aendern. Wenn eine Autobahn 
durchgehend mautpflichtig ist, koennte ja ein Tag an der Relation 
reichen. Aber siehe kuerzlich gefuehrte Relationsdiskussion ;)


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Michael Kugelmann


Am 23.07.2012 12:23, schrieb Frederik Ramm:
gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot 
passiert ist:
Vorweg: ein rießen Dank an Frederik für das schnell Entwicken und 
Bereitstellen!


[Als Anregung zum nachdenken]
An "alle" welche "verzweifelt" nach einem Tool geschreihen haben: da 
wird noch während der Bot aktiv ist und die Entwickler noch arbeiten 
sofort rumgemeckert und "alles in ist Sche geschrieben". Und wenn 
die Abstellmaßnahmen dann nach kürzester Zeit da sind wird von diesen 
Leuten nicht mal "Danke" an diejenigen gesagt, welche es mit viel 
Aufwand und trotz "anderer Aufgaben" bewerkstellen...   :-(



Grüße,
Michael.


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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Harald


Hi Frederik,

ich finde das prima, was du da gebastelt hast. Danke!

Toll wäre es, wenn es auch ein Plugin für JOSM geben würde (so wie das 
Lizenzprüfungsplugin). O:-)


Schönen Abend noch

Harald


Am 23.07.2012 12:23, schrieb Frederik Ramm:

Hi,

  auf

http://tools.geofabrik.de/osmi/?view=redactionbot&lon=7.84268&lat=48.78466&zoom=5 



gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot 
passiert ist:


ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten 
Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen!


ORANGE - Sachen, die der Bot geaendert hat.

GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand 
anders nochmal angefasst wurden.


Bye
Frederik



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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden fly

On 23/07/12 19:55, Toni Erdmann wrote:
> On 07/23/2012 06:37 PM, aighes wrote:
>> Am 23.07.2012 18:27, schrieb Toni Erdmann:
>>> On 07/23/2012 06:17 PM, Garry wrote:
 Am 23.07.2012 17:24, schrieb Michael Herbold:
> Hallo,
>
> erst mal vielen vielen Dank für das zahlreiche und konstruktive
> Feedback.
>
> Wir haben heute früh schon angefangen, die Strecken entsprechend zu
> taggen (siehe http://www.openstreetmap.org/user/synyx/edits).
>
> Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da
> die
> Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
> und würden dies auch an den bereits erstellen Tags anpassen (thx @
> jimmy
> für den Vorschlag).

Bitte verwendet besser verständliche Tags. Mit N2 bzw N3 kann man nicht
viel anfangen und erschließen lassen sich solche Abkürzungen auch nicht.

Auch kann man nicht so einfach einen neuen access tag einführen.

>>>
>>> hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen.
>>> Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann
>>> Toll zahlen muss.
>>>
>>> toll:EU:N3
>>>
>>> oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben.
>> ...nur das damit keiner mehr etwas anfangen kann.

Sowas sollte man auf jedenfall vermeiden und lieber eine Bezeichnung

>> Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie
>> toll:hgv:(weight>12)=yes

Finde ich schon verständlicher.

Wäre diese Diskussion nicht besser bei tagging@ aufgehoben ?


Gruß
fly



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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Steffen van Bergerem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

von mir auch ein großes Dankeschön! Es erleichtert das Remapping doch
ungemein, wenn man direkt auf einen Blick die Lücken erkennt.

Am 23.07.2012 21:24, schrieb Christian Hauer:
> Hallo,
> 
> vorweg einmal: danke, super Arbeit!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQDadRAAoJEOxzIRGma6mXZWUH/0dtd7VN/ZanEjgV1qJrE2QD
4GylfhrhQ6mpKzIlT3ZwHofba22lbouo/RGPT/P0hWPsF9jp1qI+NkcpfBSifCfD
2iDMJMb6eMulg2nZGRSUA3L99OexBdQEvhUXlMfPzqV0Rce0wY50Yz3v9S+SMLaH
ruKfo9mHAUL8wsLhYYNic3lEAdYID2uc6cLw6xtQpfxYd2luKpVOXiN5AAKKpoh7
7XlOT2iE8Vc2zJECLW+78drpg1nI+jilD1NBdNJ27XzGK3VdEKzjw7qD9DIKueSQ
QfDVnphJ/olsomcK8GVe5beUqDD3dxjwBiUGUxlBnSrdj4i9uS/wEuIc1B5eGv4=
=tyAj
-END PGP SIGNATURE-

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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Christian Hauer


Hallo,

vorweg einmal: danke, super Arbeit!


Am 2012-07-23 12:43, schrieb Hartmut Holzgraefe:
von der "logischen" Abstufung rot-orange-gelb her ist das zwar völlig 
OK und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so 
meine Probleme, insb. wenn es über highway=tertiary liegt ... :( 
Wenn ich etwas monieren könnte, dann wäre es wohl auch die Farbwahl. 
Wenn da noch was geändert würde, würd ich mich sicher nicht beschweren 
... ;)



Frederik Ramm  wrote:

..., aber es gab Leute, die
meinten, man sollte das noch sehen koennen.

Der Meinung bin ich auch.


Am 2012-07-23 15:24, schrieb Sven Geggus:

Ich meine wenn jemand einen solchen Weg in den
Fingern hatte, dann ist der doch meist wieder OK oder?

Jein, nicht zwangsläufig.
Ich habe in Wien im 4., 5. und 6. Bezirk mittlerweile auch einiges an 
Straßen korregiert bzw neu angelegt, und das hauptsächlich basierend auf 
dem Wiener Stadtplan.
Das heißt aber noch nicht unbedingt, dass ich dadurch auch alles 
erfassen konnte, was vorher eingetragen war. Für Leute, die zB aufgrund 
persönlichen Wissens Informationen haben, die über den Stadtplan 
hinausgehen ist es mMn sehrwohl wichtig zu wissen, dass dieser Way/Node 
vom Bot betroffen war und da potenziell nach Daten fehlen könnten.


Lg
Christan
user:grimnirson


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

Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)

2012-07-23 Diskussionsfäden Rainer Dorsch

Am Sunday 22 July 2012 schrieb Tobias Knerr:
> Am 22.07.2012 21:34, schrieb aighes:
> > Deutlich besser: Mach eine Liste draus, zerhacke sie in sinnvolle
> > Paketgrößen und pack sie auf eine Wiki-Seite. Wie bei anderen ähnlichen
> > Aktionen üblich.
> 
> Würde ich auch besser finden. Ich halte solche Listen zwar grundsätzlich
> schon für hilfreich, aber habe jetzt natürlich keine Ahnung, ob schon
> jemand Einträge darauf abgearbeitet hat, und wenn ja welche.
> 
> Sollte nächstes Mal besser wie eine der älteren Aktionen im Wiki
> aufgezogen werden:
> http://wiki.openstreetmap.org/wiki/Aktionen
> 
> Und dann _eine_ Mail mit Link auf die entsprechende Wikiseite schicken.
> 

Die Wiki-Seite aufsetzen schaffe ich vermutlich nicht alleine, gibt es 
Freiwillige die den Teil übernehmen können und wollen?

Danke und Gruß
Rainer
-- 
Rainer Dorsch
http://bokomoko.de/

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Toni Erdmann


On 07/23/2012 06:37 PM, aighes wrote:

Am 23.07.2012 18:27, schrieb Toni Erdmann:

On 07/23/2012 06:17 PM, Garry wrote:

Am 23.07.2012 17:24, schrieb Michael Herbold:

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive
Feedback.

Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da
die
Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @
jimmy
für den Vorschlag).



hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen.
Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann
Toll zahlen muss.

toll:EU:N3

oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben.

...nur das damit keiner mehr etwas anfangen kann.

Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie
toll:hgv:(weight>12)=yes



ich weiß, kaum hatte ich die Mail mit "toll:EU:N3" abgeschickt, fiel mir
was anderes (besseres?) bzw. Gegenargumente ein.

Toni

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Philip Gillißen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 23.07.2012 15:22, schrieb Jimmy_K:
> Kommt aus dem Englischen Raum. International eher unter LGV (Large
> Goods Vehicle) bekannt. Wird für Fahrzeuge genommen, welche unter
> die Kategorie N2 und N3 der EU fallen (somit Fahrzeuge zur
> Güterbeförderung über 3,5t bis 12t und über 12t).
Danke für die Info!

>> An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir
>> und ich denke da nur an Martin) dran stoßen. Das hieße, dass ein
>> nicht existierendes Tag eine Information ist. Das ist meiner
>> Meinung nach nicht so gewollt, da nicht gepflegte Tags nicht
>> bedeuten, dass dahinter eine Information liegt. Diese
>> Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen
>> sehr leicht entstehen.
> Es wäre nicht der erste Tag, welcher standardisiert auf yes
> gesetzt wird. (auf der Autobahn z.b. auch oneway), falls ich deine
> Kritik richtig verstanden habe.

Ich fürchte, ich habe mich ungenau ausgedrückt.
Wenn man nur die Autobahnen mit toll:hgv=no setzt, von denen man weiß,
dass sie mautfrei sind, finde ich das ok. Problem ist aber (wie bei
oneway=yes), dass der Umkehrschluss gefährlich ist.
Nur weil ein Way kein toll:hgv=no (bzw. kein oneway=yes) hat, heißt es
nicht, dass der Weg mautbelegt (bzw. keine Einbahnstraße) ist.

Gruß, Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlANixsACgkQYNYFUFLXAD1rPwCfSjUSR9+Ly+oY/ePVW6df1yQM
7lQAnRmylirniGBVfqibpuC2WbXnPSwp
=sogR
-END PGP SIGNATURE-

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

Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)

Danke für die Liste!
Eine fehlende turn restriction hat ein Loch in der B92 nähe Klagenfurt
aufgezeigt, da hätte es massive Routing Probleme gegeben.

LG Jimmy




PS: Zusätzlich habe ich gelernt, dass in der ein oder anderen
Volksschule maximal 30km/h erlaubt sind :D

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

Re: [Talk-de] Permanente/stabile OSM IDs!



Am 23.07.2012 17:41, schrieb Stefan Keller:

Am 23. Juli 2012 13:16 schrieb aighes :

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
"verliert" (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID

Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?


Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.

Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.
Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl 
nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall 
sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen 
Objekt passen.


Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, 
wäre es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man 
will also wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden 
kopieren der UUID merkt man davon leider nicht viel.


Henning


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

Re: [Talk-de] LKW Mautinformationen


Am 23.07.2012 18:27, schrieb Toni Erdmann:

On 07/23/2012 06:17 PM, Garry wrote:

Am 23.07.2012 17:24, schrieb Michael Herbold:

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive 
Feedback.


Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da 
die

Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @ 
jimmy

für den Vorschlag).



hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen.
Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann
Toll zahlen muss.

toll:EU:N3

oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben.

...nur das damit keiner mehr etwas anfangen kann.

Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie 
toll:hgv:(weight>12)=yes


Henning


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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Toni Erdmann


On 07/23/2012 06:17 PM, Garry wrote:

Am 23.07.2012 17:24, schrieb Michael Herbold:

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback.

Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die
Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy
für den Vorschlag).



hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen.
Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann
Toll zahlen muss.

toll:EU:N3

oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben.

Just my 2 [EUR]ct.

Gruß,
Toni

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Garry


Am 23.07.2012 17:24, schrieb Michael Herbold:

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback.

Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die
Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy
für den Vorschlag).
Hier sollte man nur im Hinterkopf behalten dass die 12Tonnen Maut kein 
"Naturgesetz" ist.
Ein Herabstufung auf 7,5Tonnen wurde auch schon diskutiert, eine 
parallele PKW-Maut mit abweichendem
und/oder zeitabhängigem mautpflichtigem Strassennetzt wäre auch 
denkbar(Stichwort Verkehrslenkung).

Die Problematik mit den impliziten Informationen ist uns bewusst.
Prinzipiell haben wir kein Problem damit, dass mautpflichtige Autobahnen
mit toll:N3=yes getaggt werden. Wie Jimmy schrieb, schliesst das eine
das andere nicht aus. Wir haben bislang eben nur die mautfreien Teile
getaggt. Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu
taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück
in Deutschland den Tag erhalten würde.
Anderst wird es schwer zu unterscheiden ob ein Abschnitt nicht 
mautpflichtigt oder nur nicht getaggt ist.


Garry

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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Henning/aighes

Am 23. Juli 2012 13:16 schrieb aighes :
> Am 23.07.2012 12:38, schrieb Manuel Reimer:
>
>> Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
>> gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
>> als kleine "Pinnadeln" gezeigt werden. Beim Anklicken der "Pinnadel" geht
>> ein Popup mit kurzem Text und einem Foto auf.
>>
>> Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto
>> mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich
>> in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich
>> stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder
>> einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so
>> nett und zieht beim Umbauen von "Node" auf "Way" alle Tags mit um. Dann
>> passt es direkt wieder.
>
>
> Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte
> Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn
> jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID?

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
"verliert" (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID

>> Das "Permanent ID Konzept" taugt für mich garnicht, denn für die meisten
>> Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als
>> "Bildstock" auszeichnet.

Das ist genau der Grund, der für die Projekt-ID spricht.

> Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
> frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.

Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.

LG, Stefan


Am 23. Juli 2012 13:16 schrieb aighes :
> Am 23.07.2012 12:38, schrieb Manuel Reimer:
>
>> Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
>> gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
>> als kleine "Pinnadeln" gezeigt werden. Beim Anklicken der "Pinnadel" geht
>> ein Popup mit kurzem Text und einem Foto auf.
>>
>> Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto
>> mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich
>> in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich
>> stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder
>> einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so
>> nett und zieht beim Umbauen von "Node" auf "Way" alle Tags mit um. Dann
>> passt es direkt wieder.
>
>
> Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte
> Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn
> jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID?
>
>
>> Das "Permanent ID Konzept" taugt für mich garnicht, denn für die meisten
>> Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als
>> "Bildstock" auszeichnet.
>
> Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
> frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.
>
> Henning
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Stephan Wolff


Moin!

Am 22.07.2012 22:58, schrieb Frederik Ramm:

Hallo,

ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind,
auf die sich niemand sonst verlassen darf, weil dies die
Handlungsmoeglichkeiten bei OSM einschraenkt.


+1


Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant,
und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf
die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit
umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder
nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir
brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt...


Die Unklarheit der Zuordnung ist allerdings kein spezifisches Problem 
der UUIDs, sondern tritt bei allen Tags (name, height, url, ...) auf.

Selbst wenn ein Mensch die Zuordnung meist richtig macht, kann eine
Software das in der Regel nicht.
Nur wenn man generell Gebäude und Gebäudenutzer als getrennte
OSM-Objekte anlegt, gibt es solch Probleme nicht.


Laut Overpass's Permanent ID könnte die Lösung eine "eindeutige
Eigenschaft" des Objekts sein, typischerweise eine Kombination von
Tags. Als Beispiel wird eine Relation mit den Tags "network=BAB" und
"ref=A 516" herangezogen.


Ohne eine eindeutige Kombination aus name, ref, network, etc. wird es
schwierig. Bei der "A 516" wird es wohl funktionieren, die "B 1" ist
schon schwieriger, bei Bahnstrecken oder anderen ausgedehnten Objekten
ohne ref wird es oft unmöglich.


Was aber eine gute Idee waere:

Man baut eine externe Datenbank als Interface zwischen der
Oeffentlichkeit und OSM auf.
Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat
dieses Vorgehen den Vorteil, dass alle Links in der Datenbank
regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch
gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0
oder 2?


Das setzt voraus, das es zu jedem realen Objekt genau ein OSM-Objekt
gibt. Vor- und Nachteile hatten wir gerade im Thread "Relationen aus
der Sicht der Auswertung - Segen oder Fluch??" diskutiert.

Viele Grüße
Stephan






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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Michael Herbold

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback.

Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die
Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy
für den Vorschlag).

Die Problematik mit den impliziten Informationen ist uns bewusst.
Prinzipiell haben wir kein Problem damit, dass mautpflichtige Autobahnen
mit toll:N3=yes getaggt werden. Wie Jimmy schrieb, schliesst das eine
das andere nicht aus. Wir haben bislang eben nur die mautfreien Teile
getaggt. Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu
taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück
in Deutschland den Tag erhalten würde.

Weiterhin würden wir die entsprechenden Wiki Seiten bezüglich dem Thema
Maut ergänzen, damit die oben genannte Information schriftlich
festgehalten und nachvollziehbar ist.

Bezüglich der Lizenz sehen wir keine Probleme, da das Tagging auf Basis
von Gesetzen erfolgt, dessen Text öffentlich verfügbar ist (siehe
http://www.mauttabelle.de/faq.html#wog).

Vielen Dank nochmals für die Rückmeldungen.

Grüße
Michael

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

Re: [Talk-de] LKW Mautinformationen

Am 23.07.2012 14:15, schrieb Robert S.:
>> toll:hgv=yes (bzw. no, siehe Autobahnen)
>> (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll)
>>
> HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber
> erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen
> Wert nachdenken - z.B. LGV.
>
> Autobahnen

LGV wäre der "selbe" Fehler. Da ich es jetzt zum wiederholten Male
anspreche, habe ich die Richtline rausgesucht (2001/116/EG) [1]

Hier gäbe es die Einteilung (im Anhang II auf Seite 39):
3,5t bis 12t: Klasse N2
über 12t: Klasse N3
Somit mein Vorschlag:
toll:N3=*


LG Jimmy

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

Re: [Talk-de] LKW Mautinformationen

Am 23.07.2012 13:46, schrieb Volker Schmidt:
> Was der LKW-Fahrer braucht, ist ein Verfahren, dass ihm sagt, wo er mit
> seiner generell bezahlten Deutschland-Maut durchfahren darf und wo nicht.
> Ob das geht, ohne das spezifische Mautsystem zusaetzlich zu taggen, ist mir
> nicht klar.
>
>

Habe mich jetzt ein bisschen über das deutsche Mautsystem für Fahrzeuge
über 12t informiert. Nebenbei, da wäre z.b. ein "toll:N3=yes" vielleicht
passender, denn bei hgv (als N2 und N3) sind ja auch Fahrzeug von 3,5
bis 12t eingeschlossen.

Welche abweichenden Mautsysteme gibt es in Deutschland? Ich konnte nur
"das Eine" finden.


LG Jimmy

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Peter Wendorff


Am 23.07.2012 13:34, schrieb Stefan Keller:

Hallo Georg,

Am 23. Juli 2012 06:31 schrieb Georg Feddern :


Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten
ref-Attribut?

Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von
einem ref-Attribut unterscheiden:
Eine Projekt-ID...
1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft
erst mit network zusammen eindeutig - wenn überhaupt)
eine Projekt-ID lässt sich dagegen nicht osm-intern z.B. über ein 
network-Tag überprüfen, sondern nur mithilfe einer sonstwo verstreuten 
Datenbank des betreffenden Projekts. Ohne dieser Datenbank ist sie 
genausowenig eindeutig.

2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces
enthalten (wie das mit "A 533" der Fall ist)
was hat das jetzt damit zu tun? abgesehen davon, dass ich durchaus in 
meinem Projekt IDs mit Spaces erzeugen könnte; nicht besonders gut les- 
aber machbar.

3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als
OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil
eines "Ganzes"

Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob
eine Kombination von Attributen (name+ref+network) den gleichen Nutzen
bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was
lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben
weder Namen noch ein ref-Tag.

amenity=bench + in_bbox()
amenity=parking_slot (oder wie auch immer da jetzt der aktuelle Stand 
ist) + has_coordinate(lat, lon)


wie jemand anders ja schon festgestellt hat, ist die Koordinate durchaus 
auch eine ID.


Wenn ich die Parkplätze untereinander unterscheiden will, sollte ich 
vielleicht geometrische abfragen innerhalb des Gesamtparkplatzes 
(amenity=parking) darauf ausführen, so dass ich sowas formulieren kann wie:


amenity=parking_slot at [amenity=parking, parking=surface, in_bbox()] 
[3rd-row, 42nd column].


Ob das aber wirklich noch jemand machen will, ohne sich die 
entsprechenden Dinger lokal zu speichern...


Gruß
Peter

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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Sven Geggus

Frederik Ramm  wrote:

> Ja, das ist ein bisschen bloed, aber Du kannst ja voruebergehend oben am 
> Transparenz-Schieber den Hintergrund wegblenden. Eigentlich wollt ich 
> die Sachen, die gelb sind, ganz rauslassen, aber es gab Leute, die 
> meinten, man sollte das noch sehen koennen.

Na ja sind die nicht grün? Ich meine wenn jemand einen solchen Weg in den
Fingern hatte, dann ist der doch meist wieder OK oder?


Sven

-- 
If you can spend five minutes on the Internet and do not run Linux,
you're a genius. (Dirk Hohndel)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] LKW Mautinformationen

Am 23.07.2012 13:00, schrieb Philip Gillißen:
> Hallo Michael!
>
> Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen
> soll.

Kommt aus dem Englischen Raum. International eher unter LGV (Large Goods
Vehicle) bekannt. Wird für Fahrzeuge genommen, welche unter die
Kategorie N2 und N3 der EU fallen (somit Fahrzeuge zur Güterbeförderung
über 3,5t bis 12t und über 12t).
>
> Michael Herbold wrote
>> Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
>> den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
>> haben, erhalten toll:hgv=no.
>>
> An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir und ich
> denke da nur an Martin) dran stoßen. Das hieße, dass ein nicht existierendes
> Tag eine Information ist. Das ist meiner Meinung nach nicht so gewollt, da
> nicht gepflegte Tags nicht bedeuten, dass dahinter eine Information liegt.
> Diese Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen sehr
> leicht entstehen.
>

Es wäre nicht der erste Tag, welcher standardisiert auf yes gesetzt
wird. (auf der Autobahn z.b. auch oneway), falls ich deine Kritik
richtig verstanden habe.
Auf jeden Fall wird nichts beschädigt, wenn auf eine mautfreie Autobahn
toll:hgv=no gesetzt wird. Und alle die es anders wollen, setzen auf die
mautbehafteten Autobahnen ein toll:hgv=yes. Die eine Methode schließt
die andere ja nicht aus.


LG Jimmy

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Rainer Kluge


On 23.07.2012 14:22, Stefan Keller wrote:

Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines
kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und
wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen
ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich
nochmals komplett neu zu erfassen.


Der Vergleich mit einer Kundendatenbank hinkt. Gibt es keine Referenz per 
interner ID von und zu einem Kundensatz, dann kann dieser problemlos gelöscht 
und neu angelegt werden. Wenn aber die Kundendaten über eine interne ID noch mit 
Bestelldaten verknüpft sind, dann kann der Kundendatensatz nicht gelöscht 
werden. Vergleichbares ist bei den hier diskutierten Beispielen in OSM nicht 
möglich, da die Verknüpfung in der externen Anwendungsdatenbank realisiert ist.



Der Mapper soll nun natürlich gemäss seiner Wahrnehmung der Realität
entscheiden, was nun mit den Bänken geschehen sein könnte:
Entscheidet er sich dafür, dass sie verschoben wurden, soll er das mit
den vier Bänken tun (unter Beibehaltung der Projekt-ID bei der einen).
Meint er, das seien vier brandneue, löscht er die vier (inkl.
Projekt-ID) und erfasst vier neue (ohne Projekt-ID). Das
Schlafbank-Projekt kriegt ja beides mit und muss reagieren.


Nein, der gemeine Mapper nimmt die alten Bänke, verschiebt sie, ändert deren 
OSM-Tags und fasst deine Projekt-ID dabei nicht an. Er tut OSM damit was Gutes, 
weil er 4 OSM-IDs spart. Oder er macht sich Gedanken über diese Projekt-ID, 
verliert Zeit mit der Suche nach deren Bedeutung und dem Umgang mit ihr, ist 
verunsichert und lässt alles beim Alten, schliesslich will er ja nichts kaputt 
machen. Beides ist sicher nicht im Sinne des Schlafbankprojekts.


Gruß
Rainer






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

Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)

2012-07-23 Diskussionsfäden Robert Kaiser


Ich leite das mal an talk-at weiter...

Rainer Dorsch schrieb:

Hallo,

hier die Warnungen für die Österreich:

turn restrictions:

OSM Warning:http://www.openstreetmap.org/browse/relation/92427 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/223509 turn
restriction: via member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/241646 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/278859 turn
restriction: via member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/278860 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/278862 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/302959 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/311734 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/535236 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1318143 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1476938 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1485409 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1492801 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1506472 turn
restriction: multiple from members
OSM Warning:http://www.openstreetmap.org/browse/relation/1527515 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1683246 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1696176 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1696177 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1733647 turn
restriction: multiple from members
OSM Warning:http://www.openstreetmap.org/browse/relation/1779147 turn
restriction: from member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1790945 turn
restriction: via member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1857345 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1866773 turn
restriction: multiple to members
OSM Warning:http://www.openstreetmap.org/browse/relation/2090704 turn
restriction: multiple via member
OSM Warning:http://www.openstreetmap.org/browse/relation/2130728 turn
restriction: to member missing
OSM Warning:http://www.openstreetmap.org/browse/relation/1389144 turn
restriction: from member not found
OSM Warning:http://www.openstreetmap.org/browse/relation/1389152 turn
restriction: from member not found
OSM Warning:http://www.openstreetmap.org/browse/relation/2102804 turn
restriction: to member not found
OSM Warning:http://www.openstreetmap.org/browse/relation/2182619 turn
restriction: from member not found


polygon Warnungen:
OSM Warning:http://www.openstreetmap.org/browse/way/34495781 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/44840922 Broken polygon,
area is 0
OSM Warning:http://www.openstreetmap.org/browse/way/51852521 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/72765511 Broken polygon,
area is 0
OSM Warning:http://www.openstreetmap.org/browse/way/101693601 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/116909398 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/123449371 Broken polygon,
area is 0
OSM Warning:http://www.openstreetmap.org/browse/way/151237729 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/162979331 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/165962199 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/169695178 Broken polygon,
less than 3 points defined
OSM Warning:http://www.openstreetmap.org/browse/way/171490446 Broken polygon,
less than 3 points defined








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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Robert S.

2012/7/23 Bernd Wurst 

> Am 23.07.2012 14:15, schrieb Robert S.:
> > Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem
> > letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke
> > vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder
> > Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied,
> ob
> > man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt,
> oder
> > ob man nur an einer Stelle ist, an der man das befahren von
> > kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann.
> > Unterschiedlich erfasen und wenn ja wie?
>
> Das ist vergleichbar mit dem Erfassen von "noexit=yes" an Sackgassen die
> in einer Wendeplatte Enden. Ich bin strikt dagegen. (noexit am letzten
> Node einer Sackgasse ohne Wendeplatte finde ich gut, aber das ist ein
> anderes Thema.)
>

In der mapping-Praxis dürfte noexit=yes überall dort erfasst sein, wo auch
das entsprechende StVO-Schild steht - unabhängig von einer
Wendemöglichkeit. Analog dazu habe ich auch schon an einem langen
Autobahnzubringer ein Schild "LKW-Maut in 10 km" gesehen.

Dass man diese Zubringer im Fall der Fälle meiden sollte, lässt sich bei
> Bedarf sehr einfach berechnen.


Berechnen, berechnen Entschuldigung, aber ich bin der Meinung, dass man
OSM-Daten auch ohne Informatik-Diplom auswerten können sollte.


> Ein Navi das auf "keine Mautstraßen"
> eingestellt ist, wird den Zubringer einfach nicht nutzen, da es damit
> keine passende Route zustande bekommt.
>

Wir mappen ja nicht (nur) für die Navis.


> Du hast das wesentliche Argument schon genannt: Wenn man auswerten will,
> wie viele km mautpflichtiger Strecke man fährt, dann sollte das auch zu
> der Deklaration passen, also nur dort getagged sein wo es auch so ist.


Deshalb ja die Frage nach der unterschiedlichen Erfassung. Wenn man die
Strecken, auf denen tatsächlich die km-Maut erhoben wird mit 'toll:hgv=yes'
erfasst und die abhängigen Zubringer mit einem anderen Wert, kann man die
angesprochene Auswertung trotzdem problemlos machen, ohne die Zubringer
außer Acht zu lassen.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] LKW Mautinformationen

> HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber
> erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen
> Wert nachdenken - z.B. LGV.
>

Auch LGV ist nicht so gut, denn in GB ist HGV (Heavy goods vehicle) durch
LGV (Large goods vehicle) ersetzt worden, immer mit derselben Grenze von
3.5 metrischen Tonnen (https://en.wikipedia.org/wiki/Large_goods_vehicle)

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Lars Lingner

Hallo Michael,

On 23.07.2012 12:53, Michael Herbold wrote:
> Hallo zusammen,
> 
> ich arbeite für die Firma synyx, die sich darauf spezialisiert hat
> Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln.
> 
> Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für
> LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen
> (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir
> gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und
> für die Community zur Verfügung stellen.
> 

Vor 2 Jahren wurden die (damals) aktuellen Daten bereits für OSM zur
Verfügung gestellt. Ich habe sie daraufhin in das Shapefile-Format
konvertiert und es gibt auch einen WMS-Layer, der die Daten visualisiert.

Da sich aber niemand fand, der sich um ein sinnvolles Tagging Gedanken
machen wollte, gab es letztendlich keinen Import.

Nachzulesen ist der letzte Stand auf
http://wiki.openstreetmap.org/wiki/Mautdaten

Es ist schön zu sehen das es Interesse an Mautinfos gibt. Vielleicht
hilft ja die Vorarbeit den Aufwand jetzt zu reduzieren.

Lars

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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Bernd Wurst

Am 23.07.2012 14:15, schrieb Robert S.:
> Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem
> letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke
> vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder
> Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied, ob
> man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt, oder
> ob man nur an einer Stelle ist, an der man das befahren von
> kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann.
> Unterschiedlich erfasen und wenn ja wie?

Das ist vergleichbar mit dem Erfassen von "noexit=yes" an Sackgassen die
in einer Wendeplatte Enden. Ich bin strikt dagegen. (noexit am letzten
Node einer Sackgasse ohne Wendeplatte finde ich gut, aber das ist ein
anderes Thema.)


Dass man diese Zubringer im Fall der Fälle meiden sollte, lässt sich bei
Bedarf sehr einfach berechnen. Ein Navi das auf "keine Mautstraßen"
eingestellt ist, wird den Zubringer einfach nicht nutzen, da es damit
keine passende Route zustande bekommt.

Du hast das wesentliche Argument schon genannt: Wenn man auswerten will,
wie viele km mautpflichtiger Strecke man fährt, dann sollte das auch zu
der Deklaration passen, also nur dort getagged sein wo es auch so ist.

Gruß, Bernd

-- 
In Binärzahlen zu zählen geht genauso wie in Dezimalzahlen zählen,
nur daß man dafür nur die Daumen braucht.



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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Peter

Am 23. Juli 2012 09:02 schrieb Peter Wendorff :
> Am 22.07.2012 23:34, schrieb Stefan Keller:
>
>> Hallo Henning (aighes)
>>
>> Am 22. Juli 2012 23:05 schrieb aighes :
>>>
>>> Am 22.07.2012 22:45, schrieb Stefan Keller:

 Am 22. Juli 2012 22:14 schrieb aighes :
>
> Oder wenn jemand das Objekt nun
> anderweitig nutzt. Bspw. Straße -> Gebäude. Dann hat auf einmal das
> Gebäude die ref der Straße.

 Verstehe ich nicht.

 Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
 Datenbank für alle sein kann und einfach vollgestopft werden soll mit
 Tags, die von externen Projekten kommen. Der einzige Tag den ich
 vorschlage ist diese eine Projekt_ID.
>>>
>>> Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen
>>> Vorteil
>>> gegenüber der normalen Objekt-ID.
>>
>> Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht
>> genügt).
>>
>>> Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem
>>> Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält
>>> die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es 
>>> ihm
>>> nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich
>>> gehört, oder zu dem Objekt Restaurant.
>>
>> Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet.
>> Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht,
>> dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität
>> überein (und die externe Datenank registriert das) oder mit dem Mapper
>
> Mit dem Mapper stimmt alles, denn OSM-IDs sind Schall und Rauch und nur zur
> akuten Verwendung zwischen Objekten stabil - und an der Stelle hat der
> Mapper definitiv nichts falsch gemacht.

Ja, schon Frederik hat in die Richtung argumentiert. Wie ich ganz zu
Beginn schon gesagt habe: Entweder das Projekt kann mit unstabilen
OSM-IDs leben - oder es muss sich was einfallen lassen.

> Der betreffende Mapper ist eben vielleicht kein Datenbank-Fetischist, weiß
> unter Umständen nicht mal, was eine ID ist, und braucht das auch nicht
> wissen.

Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines
kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und
wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen
ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich
nochmals komplett neu zu erfassen.

>> :-> Will anständigerweise sagen, er war sich seiner unbedarften
>> Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt
>> das Restaurant wieder (mit seiner Projekt-ID) und löscht die
>> Projekt-ID beim Parkbank.
>
> "Das Projekt" - egal ob du damit jetzt den OSM-Server oder einen beliebigen
> Editor meinst, weiß aber nunmal gar nicht, ob der mapper damit wirklich das
> Objekt verändert hat.

Mit Projekt meine ich z.B. eine Parkbänke- oder eine
Einzelparkplatz-Datenbank. Die vergibt nun solche Projekt-IDs jedem
OSM-Objekt, das es interessiert als stabile Alternative zur OSM-ID.

> Vielleicht ist die Bushaltestelle gar nicht durch ein anderes Objekt ersetzt
> worden, sondern nur durch ein neues Taggingschema, das die Software noch
> nicht kennt - deshalb aber ja nicht verboten ist.

Verboten ist nichts - nur bitte die Arbeit anderer (also hier u.a. die
Projekt-ID) stehen lassen (ausser die Bushaltestelle wurde in der
Realität aufgehoben).

> Deine Lösung erfordert also entweder festgelegte Tagging-Regeln, damit
> solche Ersetzungsregeln auch nur ansatzweise funktionieren (denn auch ein
> nachträgliches hinzufügen/hinterherziehen neuer Taggingvarianten würde sonst
> ja das brechen von IDs nicht verhindern), oder aber es funktioniert
> schlichtweg nicht.

Meine Lösung umfasst alle Eigenschaften des
Overpass-Permanent-ID-Konzepts, grenzt es ein, damit der Tag als ID
erkenntlich wird und weitet es aus auf sämtliche OSM-Objekte.

> Dass sich ein Objekt in zwei jeweils nur einzelne Aspekte dessen
> beschreibende teilt, ist damit übrigens auch noch nicht gelöst.
>
>>> Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit
>>> dem Namen xyz in der BBox... zu fragen.
>>
>> Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke
>> leider kaum. Daher ist die Idee der kombinierten Tags unzureichend.
>
> Ich mappe am Montag vier Bänke auf dem Marktplatz.
> Eine davon (!) bekommt am Dienstag eine ID nach deinem Schema vom
> Schlafbank-projekt ;).
>
> Ich komme Freitags wieder vorbei und da stehen immer noch vier Parkbänke,
> aber nicht an der gleichen Stelle.
> Es ist definitiv nicht zu erkennen, ob die Bänke jetzt verschoben worden
> sind, oder ob das andere Bänke sind.

Nun kommen wir der Sache näher (interessantes Projekt: "Schlafbänke"
:->): Du musst dich als reiner OSM-Mapper in diesem Falle um nichts
kümmern - nur die Bänke erfassen (es könnten auch Einzelparkplätze
sein). Das Schlafbank-Projekt (vgl. Frederiks Vorschlag der externen
DB oben) hat am Montag "erkannt", da

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Robert S.

2012/7/23 Michael Herbold 

> Hallo zusammen,
>
> ich arbeite für die Firma synyx, die sich darauf spezialisiert hat
> Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln.
>
> Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für
> LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen
> (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir
> gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und
> für die Community zur Verfügung stellen.
>

Uns wurden schon 2010 die Mautdaten für das damalige Autobahnnetz gespendet:
http://wiki.openstreetmap.org/wiki/Mautdaten
Bisher wurden die Daten aber leider noch nicht eingepflegt.
Ich hatte mir ursprünglich vorgenommen, mich nach dem Lizenzwechsel (+ ein
paar Wochen zum ggf. Lückenschließen) damit zu beschäftigen. Wobei mir
bisher nicht klar ist, wie man mit Shapefiles umgeht...


> toll:hgv=yes (bzw. no, siehe Autobahnen)
> (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll)
>

HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber
erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen
Wert nachdenken - z.B. LGV.

Autobahnen
> --
> Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
> den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
> haben, erhalten toll:hgv=no.


Bitte nicht. Das widerspricht dem sonst in OSM üblichen Vorgehen. Und wenn
man weiß, wie man es machen muss, ist das jetzt auch nicht so mühsam. Wenn
man mir die nötigen Daten zur Verfügung stellt, würde ich mich auch bereit
erklären, das zu übernehmen.

Bundesstraßen
> -
> Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der
> kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt.
>

Auf der Seite der Mauttabelle sind die neuen Bundesstraßen auch als
Shapefile hinterlegt:
http://www.mauttabelle.de/maut.html
Vlt. könnte man da mal die Nutzungsmöglichkeit abklären.


Dann gibt es da noch Spezialfälle:
Z.B. die A6:
http://www.mauttabelle.de/maut_120a.html#a6
Die ist als Bundesautobahn eigentlich auf ganzer Strecke Mautpflichtig,
aber aus historischen Gründen um Saarbrücken herum mautfrei. Das wird
dadurch realisiert, dass man die Länge der mautpflichtigen Abschnitte
einfach mit 0 km ansetzt. Soll man das gesondert erfassen oder einfach als
nicht mautpflichtige Strecke?

Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem
letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke
vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder
Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied, ob
man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt, oder
ob man nur an einer Stelle ist, an der man das befahren von
kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann.
Unterschiedlich erfasen und wenn ja wie?
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Jochen Topf

On Mon, Jul 23, 2012 at 12:53:05PM +0200, Michael Herbold wrote:
> ich arbeite für die Firma synyx, die sich darauf spezialisiert hat
> Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln.
> 
> Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für
> LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen
> (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir
> gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und
> für die Community zur Verfügung stellen.

Da gabs schonmal ein Projekt bei dem jemand alle diese Daten für OSM
gespendet hat. Weiss nicht, was daraus geworden ist...

> Meine Kollegen und ich haben recherchiert und sind zu folgenden
> Vorschlag gekommen, wie wir das Kartenmaterial taggen würden:
> 
> toll:hgv=yes (bzw. no, siehe Autobahnen)
> (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll)
> 
> Autobahnen
> --
> Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
> den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
> haben, erhalten toll:hgv=no.
> 
> Bundesstraßen
> -
> Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der
> kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt.

Es ist keine gute Idee, verschiedene Defaults für toll:hgv zu benutzen. Das ist
a) verwirrend, weil kontextabhängig und b) geht das jetzt von der Situation in
Deutschland aus. Was ist, wenn in Frankreich nur wenige Autobahnen Maut haben?
Soll dann in Frankreich eine andere Tagging-Regel gelten? Da die allermeisten
Straßen dieser Welt keine Maut erfordern, sollte der Default auch für alle
Straßen "no" sein.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] LKW Mautinformationen

Ich bin mir nicht sicher, dass dieses einfache System funktioniert.
toll:hgv bezieht sich hier auf ein spezifisches Maut-System in Deutschland.
Das vorgeschlagene negativ-tagging waere auch nur in Deutschalnd korrekt.

Ich sehe zwei Probleme:
die internationale Komptbilitaet des vorschlagenen tagging-Systems
ein moeglichen Konflikt mit lokalen Mautserhebungen, die nicht durch das
generelle System abgedeckt sind.

Was der LKW-Fahrer braucht, ist ein Verfahren, dass ihm sagt, wo er mit
seiner generell bezahlten Deutschland-Maut durchfahren darf und wo nicht.
Ob das geht, ohne das spezifische Mautsystem zusaetzlich zu taggen, ist mir
nicht klar.

2012/7/23 Michael Herbold 

> Hallo zusammen,
>
> ich arbeite für die Firma synyx, die sich darauf spezialisiert hat
> Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln.
>
> Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für
> LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen
> (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir
> gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und
> für die Community zur Verfügung stellen.
>
> Meine Kollegen und ich haben recherchiert und sind zu folgenden
> Vorschlag gekommen, wie wir das Kartenmaterial taggen würden:
>
> toll:hgv=yes (bzw. no, siehe Autobahnen)
> (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll)
>
> Autobahnen
> --
> Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
> den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
> haben, erhalten toll:hgv=no.
>
> Bundesstraßen
> -
> Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der
> kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt.
>
>
> Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt
> für Güterverkehr genommen. Siehe
>
> http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502
>
> Falls jemanden etwas einfällt, dies nicht zu tun, der soll sich bitte
> umgehend melden oder für immer schweigen :).
>
>
> Grüße
> Michael
>
>
> --
> /**
>  * Michael Herbold
>  * Senior Developer
>  *
>  * synyx GmbH & Co. KG
>  * Open Source Solutions
>  * Karlstr. 68
>  * 76137 Karlsruhe
>  *
>  * Telefon   +49 721 203823-34
>  * Fax   +49 721 203823-12
>  * E-Mailherb...@synyx.de
>  * Web   http://www.synyx.de
>  * Blog  http://blog.synyx.de
>  *
>  * Sitz der Gesellschaft: Karlsruhe
>  * Registergericht: Mannheim
>  * Handelsregisternummer: HRA 104793
>  * USt-IdNr.: DE249264296
>  *
>  * Komplementärin: synyx Verwaltung GmbH
>  * Sitz der Gesellschaft: Karlsruhe
>  * Geschäftsführer:
>  * Thomas Kraft, Markus Daniel, Joachim Arrasz
>  * Registergericht: Mannheim
>  * Handelsregisternummer: HRB 107250
>  */
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] LKW Mautinformationen

> Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen
> soll.
>
> Hgv: "Heavy goods vehicle" - OSM key fuer LKW (ich glaube ueber 3.5t)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Georg,

Am 23. Juli 2012 06:31 schrieb Georg Feddern :
> Am 23.07.2012 00:09, schrieb Stefan Keller:
>> Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht
>> solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der
>> Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines
>> Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten,
>> dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und
>> allen Tags) erhalten bleibt und bitte ein neuer Node in den Way
>> eingefügt wird und nicht - wie offenbar aktuell - der Node im Way
>> erhalten wird und die Haltestelle eine neue Node-ID erhält.
>
> Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern,
> nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich
> richtigen Ort zu plazieren, wenn es doch reicht, nur zwei Objekte (H-node,
> way-node-Tags) zu verändern?
> Wer sagt, dass die Haltestelle wichtiger ist als der node in der Straße -
> der (rein hypothetisch) ein Vermessungspunkt sein könnte?

Du scheinst Objekte von OSM (Strukturen) höher zu gewichten als
Objekte der der realen Welt.
Die Sachlage ist so: Die Haltestelle hier
http://www.openstreetmap.org/browse/node/1832873388
war vorhin ein Node zweier Ways:
http://www.openstreetmap.org/browse/node/983813495/history
Was der Mapper (bzw. JOSM) offensichtlich gemacht haben, ist, dass die
Haltestelle neu erzeugt wurde.
Die Absicht des Mappers ist und war aber eindeutig die Haltestelle von
der Strassenmitte an die Seite zu verschieben.

>> Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke
>> geht, die keinen Namen haben!

Genau. Und bitte unter Beibehaltung der OSM ID - OSM und Nachnutzern zuliebe.

> Bei solchen Argumenten fällt mir irgendwie immer ein, das auch Koordinaten
> eindeutige IDs sind ...
> Diese IDs sind dann immer eindeutig ... und passende Objekte können auch in
> einem gewissen Suchradius gefunden werden.
> Die dann extern auf andere IDs gemappt werden können, so man unbedingt will.

Stimmt: Koordinaten sind auch Identifikatoren - und darum verlieren
ein Objekt genau diese identifizierendes Attribut wenn es verschoben
wird. Daher gibt es IDs.

> Und wenn das OSM-Objekt dann verschoben wird,
> - stimmte entweder die vorherige Projekt-ID erst gar nicht (die Parkbank mit
> der Projekt-ID 123 musste sich an der Koordinate xyz befinden!)
> - oder das Projekt-Objekt wurde tatsächlich verschoben (neue Koordinate =>
> externe Zuordnung anpassen!)

Die Projekt-ID 123 bleibt in beiden Fällen hoffentlich erhalten, wenn
das Objekt nur verschoben wird - die Kundennummer einer Adresskartei
bleibt ja auch erhalten, wenn der Kunde eine andere Adresse bezieht.

> - oder es ist der ganz typische OSM-Fall: Der Mapper hat das OSM-Objekt
> komplett verändert (Projekt muss eh sein Objekt auch als OSM-Objekt
> wiederherstellen!)

Ja; wo platt is is platt - da bleibt es dem Projekt nur noch zu cachen
und zu kontrollieren, ob da wirklich in der Realität auch etwas platt
gemacht wurde.

>>> Aber wir erwarten doch auch nicht, das Mapper sich
>>> für Sitzbänke und Briefkästen irgendwelche "ref"-Attribute ausdenken
>>> müssen - dazu braucht's m.E. Projekt-IDs, oder?
>
> Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten
> ref-Attribut?

Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von
einem ref-Attribut unterscheiden:
Eine Projekt-ID...
1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft
erst mit network zusammen eindeutig - wenn überhaupt)
2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces
enthalten (wie das mit "A 533" der Fall ist)
3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als
OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil
eines "Ganzes"

Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob
eine Kombination von Attributen (name+ref+network) den gleichen Nutzen
bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was
lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben
weder Namen noch ein ref-Tag.

LG, Stefan


Am 23. Juli 2012 06:31 schrieb Georg Feddern :
> Moin,
>
> Am 23.07.2012 00:09, schrieb Stefan Keller:
>>
>> Am 22. Juli 2012 22:58 schrieb Frederik Ramm :
>> Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht
>> solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der
>> Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines
>> Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten,
>> dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und
>> allen Tags) erhalten bleibt und bitte ein neuer Node in den Way
>> eingefügt wird und nicht - wie offenbar aktuell - der Node im Way
>> erhalten wird und die Haltestelle eine neue Node-ID erhält.
>
>
> Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern,
> nur um eine OSM-interne ID an den für irgendeinen Auswerter

Re: [Talk-de] Vorschlag Supersedes


Hi,

On 07/23/2012 12:53 PM, Manuel Reimer wrote:

Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen?
Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen
"supersedes"-Tag setzen, der als Wert die alte Objekt-ID hält.


Das löst nicht das Problem "Node wird durch Way ersetzt".


Und loest nicht das Problem, dass der Mapper mehr Arbeit hat.

Und loest nicht das Problem, dass der Mapper sich fragen muss, *was* 
denn jetzt superseded wird - wenn das Restaurant auf die andre 
Strassenseite zieht, ist das dann auch ein "supersede", obwohl das alte 
Haus noch steht usw.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 23.07.2012 12:38, schrieb Manuel Reimer:
Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte 
gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und 
Sehenswürdigkeiten als kleine "Pinnadeln" gezeigt werden. Beim 
Anklicken der "Pinnadel" geht ein Popup mit kurzem Text und einem Foto 
auf.


Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + 
Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, 
dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun 
UUIDs, dann könnte ich stattdessen eine von einem Mapper 
kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt 
wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen 
von "Node" auf "Way" alle Tags mit um. Dann passt es direkt wieder. 


Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das 
benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du 
eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der 
Vorteil der UUID?


Das "Permanent ID Konzept" taugt für mich garnicht, denn für die 
meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node 
als "Bildstock" auszeichnet.
Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann 
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.


Henning


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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Chris66

Am 23.07.2012 12:53, schrieb Michael Herbold:

> Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt
> für Güterverkehr genommen. Siehe
> http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502

Mit der Lizenz sind wir etwas pingelig :-) deshalb kann es nicht
schaden, eine explizite Erlaubnis vom Bund einzuholen, diese
Daten in OSM ablegen zu dürfen.

Das vorgeschlagene Tagging (hgv:toll=yes/no) ist IMHO in Ordnung.

Chris



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

Re: [Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Philip Gillißen

Hallo Michael!

Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen
soll.


Michael Herbold wrote
> 
> Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
> den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
> haben, erhalten toll:hgv=no.
> 
An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir und ich
denke da nur an Martin) dran stoßen. Das hieße, dass ein nicht existierendes
Tag eine Information ist. Das ist meiner Meinung nach nicht so gewollt, da
nicht gepflegte Tags nicht bedeuten, dass dahinter eine Information liegt.
Diese Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen sehr
leicht entstehen.

Gruß, Philip




--
View this message in context: 
http://gis.19327.n5.nabble.com/LKW-Mautinformationen-tp5717981p5717986.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Vorschlag Supersedes

2012-07-23 Diskussionsfäden Manuel Reimer


Stefan Tiran wrote:

Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen?
Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen
"supersedes"-Tag setzen, der als Wert die alte Objekt-ID hält.


Das löst nicht das Problem "Node wird durch Way ersetzt".

Gruß

Manuel


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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate


Hallo,

On 07/23/2012 12:43 PM, Hartmut Holzgraefe wrote:

von der "logischen" Abstufung rot-orange-gelb her ist das zwar völlig OK
und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so meine
Probleme, insb. wenn es über highway=tertiary liegt ... :(


Ja, das ist ein bisschen bloed, aber Du kannst ja voruebergehend oben am 
Transparenz-Schieber den Hintergrund wegblenden. Eigentlich wollt ich 
die Sachen, die gelb sind, ganz rauslassen, aber es gab Leute, die 
meinten, man sollte das noch sehen koennen.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[Talk-de] LKW Mautinformationen

2012-07-23 Diskussionsfäden Michael Herbold

Hallo zusammen,

ich arbeite für die Firma synyx, die sich darauf spezialisiert hat
Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln.

Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für
LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen
(diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir
gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und
für die Community zur Verfügung stellen.

Meine Kollegen und ich haben recherchiert und sind zu folgenden
Vorschlag gekommen, wie wir das Kartenmaterial taggen würden:

toll:hgv=yes (bzw. no, siehe Autobahnen)
(ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll)

Autobahnen
--
Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier
den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht
haben, erhalten toll:hgv=no.

Bundesstraßen
-
Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der
kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt.

Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt
für Güterverkehr genommen. Siehe
http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502

Falls jemanden etwas einfällt, dies nicht zu tun, der soll sich bitte
umgehend melden oder für immer schweigen :).

Grüße
Michael

--
/**
* Michael Herbold
* Senior Developer
*
* synyx GmbH & Co. KG
* Open Source Solutions
* Karlstr. 68
* 76137 Karlsruhe
*
* Telefon +49 721 203823-34
* Fax +49 721 203823-12
* E-Mailherb...@synyx.de
* Web http://www.synyx.de
* Blog http://blog.synyx.de
*
* Sitz der Gesellschaft: Karlsruhe
* Registergericht: Mannheim
* Handelsregisternummer: HRA 104793
* USt-IdNr.: DE249264296
*
* Komplementärin: synyx Verwaltung GmbH
* Sitz der Gesellschaft: Karlsruhe
* Geschäftsführer:
* Thomas Kraft, Markus Daniel, Joachim Arrasz
* Registergericht: Mannheim
* Handelsregisternummer: HRB 107250
*/

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Manuel Reimer


Frederik Ramm wrote:

ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die
sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM
einschraenkt.


Mag ja sein, aber es gibt aktuell keine echte Alternative, ein Objekt in der OSM 
korrekt zu referenzieren. Es ist nunmal so, dass OSM-Intern die ID als 
Datenbank-Schlüssel verwendet wird und solange Mapper ein Objekt nicht komplett 
löschen und neu erzeugen (oder einen Node durch einen Way ersetzen, wie z.B. bei 
Gebäuden) ist die ID auch stabil.



UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der
Link-Stabilitaet unseren Mappern aufbuerden.


Und? Warum sollte nicht derjenige, der Daten aus der OSM nutzt, sich um die 
Dauerhaftigkeit dieser ID kümmern?


Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, 
auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine 
"Pinnadeln" gezeigt werden. Beim Anklicken der "Pinnadel" geht ein Popup mit 
kurzem Text und einem Foto auf.


Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache 
ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner 
DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen 
eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die 
Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim 
Umbauen von "Node" auf "Way" alle Tags mit um. Dann passt es direkt wieder.


Das "Permanent ID Konzept" taugt für mich garnicht, denn für die meisten 
Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als "Bildstock" 
auszeichnet. Ein "start_date" (sofern bekannt) wäre nicht eindeutig und Namen 
sind nur für die wenigsten Bildstöcke bekannt.



Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens nie
schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID fuer die
ganze "Bachstrasse", oder eine fuer jeden Teil-Way? Wenn ich ein
denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way
eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite -
woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem
Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem
Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt,
eine fuer jeden Aspekt...


Und?

http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID#UUID_Tagging

Gibt dann halt ein "uuid:building" für das Gebäude und ein "uuid:amenity" für 
das Restaurant. Entweder beidem am Way des Gebäudes oder das "uuid:building" am 
Gebäude und das "uuid:amenity" auf dem Node für das Restaurant. Und für meine 
Bildstöcke wäre "uuid:historic" das richtige Tag.


Aus der Liste würde ich lediglich sowas wie "uuid:operator" ersatzlos streichen. 
Das muss in Chaos enden sobald jemand einen "Operator" mit UUID versehen will, 
der z.B. Deutschlandweit aktiv ist.


Ich finde die Idee gut. Ich habe auch schon mehrfach darüber nachgedacht einfach 
eine eigene ID als Tag in die OSM-DB zu schreiben und mich dann selber um das 
Pflegen "meines" Tags zu kümmern. Ebenso könnte ich aber auch ein allgemeines 
"uuid:*"-Tag verwenden. Würde mein Problem auch lösen und wäre dann kein 
"Spezialtag", das ich erfunden habe.


Gruß

Manuel


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

[Talk-de] Vorschlag Supersedes (was: Permanente/stabile OSM IDs!)

2012-07-23 Diskussionsfäden Stefan Tiran

Stefan Keller wrote:
> Mich beschäftigt seit einiger Zeit die Frage von "permanenten/stabilen
> OSM IDs" und der Verknüpfung von OSM mit anderen Datenbanken.

Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen?
Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen
"supersedes"-Tag setzen, der als Wert die alte Objekt-ID hält.

Liebe Grüße,
Stefan

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

Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-23 Diskussionsfäden Hartmut Holzgraefe

On 23.07.2012 12:23, Frederik Ramm wrote:

> GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand
> anders nochmal angefasst wurden.

von der "logischen" Abstufung rot-orange-gelb her ist das zwar völlig OK
und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so meine
Probleme, insb. wenn es über highway=tertiary liegt ... :(

-- 
hartmut

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

[Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate