[FT-Talk] Seltsames um Burg (Fehmarn) - Bitte heute nicht mehr bearbeiten!!!

[Mario Salvini]

Olaf Hannemann schrieb:
> Hallo Mario,
>
> Sorry für die späte Antwort, aber ich wollte erst einmal etwas Zeit vergehen 
> lassen um für mich selber ruhiger zu werden. Ich denke dieser andauernde Kampf 
> tut uns allen nicht gut. Es wäre schön auf eine sachliche Ebene zurückzukehren, 
> daher jetzt noch einmal mein Versuch ganz ruhig und sachlich darzulegen wo meine 
> derzeitigen Probleme sind.
>   
sachliche Ebene is immer gut. Also Danke für die Antwort :)
>   
>>> Unentschieden würde ich sagen. Wir brauchen den seamark=* Tag nicht
>>> wirklich, dieser ist aber zur Zeit unser Schlüssel um zu entscheiden ob
>>> das Seezeichen für uns interessant ist oder nicht.
>>> Wenn ihr den Schlüssel buoy=lateral_port benutzt benötigt ihr den
>>> seamark=* Schlüssel auch nicht wirklich, Da mit dem Schlüssel buoy=*
>>> bereits gesagt ist, dass es sich um eine Tonne handelt
>>>       
>> nach eurem Schema braucht ihr seamark= im Grunde garnicht, schließlich
>> ist alles schon mit tags die mit "seamark:" starten redundant. Wenn ihr
>> also nach "seamark:" horcht findet ihr Zeichen mit eurem Schema auch zu
>> 100%.
>> Das andere Schema (ich vermeide hier extra FT-Schema zu sagen, denn
>> schließlich isses nicht "das Schema von FT") verzichtet dagegen völlig
>> auf Redundanz aus.
>>     
>
> seamark:* ist ein Namensraum diesen verwendet man um den Land-Renderern nicht in 
> die Quere zu kommen. Ähnlich wird dieses in OSM z.B. mit addr:* angewendet. Ich 
> gebe dir recht, dass dieses auf den ersten Blick redundant wirkt. Vom Prinzip 
> her könnten wir den seamark:* Schlüssel ganz weg lassen, aber spätestens wenn du 
> solche Dinge wie max_speed oder max_height erfassen möchtest bekommst du ein 
> Problem. Aus diesen Gründen setze ich allen Einträgen, die nur die Seefahrt 
> betreffen ein seamark:* voran.
>   
Begrenzungen wie z.B. maxspeed oder maxheight stehen ja im Grunde auch 
nie alleine dar, sondern sind immer mit einem Node, Way oder Area zu 
sehen. Um also Straßenbegrenzungen von Wasserbegrenzungen zu 
unterscheiden müsste also das Schauen nach highway=* (auf Land) und 
waterway=* (auf Wasser) ausreichen. (Auch wen FT bis jetzt nur Nodes 
kennt. In OSM gibts ja auch durchaus schon Ways oder Areas ;) ). Was die 
Wasserhöhe von Brücken angeht scheint sich übrigens  maxheight:sailing= 
zu festigen (laut dem proposal zur "clearance").

> Ich bin von meiner Seite her bereit auf den seamark=* Schlüssel zu verzichten, 
> da er wie von dir erwähnt nicht wirklich nötig ist. Es ist nur deshalb schade, 
> da er die Performance meines Renderers deutlich steigert. Aber wie gesagt wir 
> taggen ja nicht für die Renderer. 
Für deinen Render-Style brauchst du ja nicht drauf zu verzichten. 
Schließlich braucht man beim Render-Style kein Value, sondern kannst 
einfach nach seamark als Key horchen. Ob da jetzt "buoy_lateral" oder 
nur "buoy" oder "beacon" oder... steht würde die Performance deines 
Renderers ja nicht wirklich beeinflussen. Die eigenentlichen 
Bestandteile die gerendet werden holt ihr ja vermutlich aus den 
Detailangeben  die mit "seamark:" vorangestellt sind.
> Warum er aber für euch so wichtig ist 
> erschließt sich mir auf den ersten Blick nicht.
>   
Ist im Grunde aus dem gleichen Grund da, wie bei eurem Schema. seamark= 
markiert, dass es sich um ein Seezeichen handelt. Im zweiten Schritt 
sagt erst das Value aus, was es ist: buoy, beacon, landmark,lighthouse. 
Das bekommt sogar jede Landratte hin. Erst durch die Detailangaben buoy= 
light= toplight= wird das Seezeichen klar definiert. In der 4. Ebene 
kann man dann ggf. noch detailiertere Details erfassen ":color=",  
":shape=",  ":group_light=", etc... .  Das ist das Prinzip des 
Proposeten Schemas. Nur halt im vergleich zu eurem alternierenden Schema 
ohne Redundanz (bis aus die Redundanz sind die Schemata ja großteils 
identisch).
Euer Schema sagt halt direkt z.B. "seamark=lateral_buoy" eigentlich ja 
eher eine Mischung aus Gegenstand (Boje) und Funktion (lateral). Das 
vorgeschlagene Schema trennt da halt strikt und sagt "seamark=buoy" (da 
ist eine Boje) "buoy=lateral_port" (eine backbord (rote) Lateralboje). 
Is natürlich Ansichtssache, aber persönlich gefällt mir die klare 
Trennung besser.
> Hier noch einmal ein paar Anmerkungen zu der Funktionsweise meines Renderers. 
> Ich habe gar keinen Importfilter und möchte auch gar keinen haben. Ich arbeite 
> mit einem OSM üblichen Osmarender mit erweiterten Stylesheets. Die Daten werden 
> direkt aus der OSM-Datenbank geladen und gerendert. Ich denke, dass dies der OSM 
> übliche weg ist.
> Ich habe und möchte keine eigene  Datenbank zur Sicherung der Qualität vor 
> halten, im Gegenteil ich fände es traurig wenn dieses in Zukunft von Nöten wäre.
>  
>   
>>>> Nochmal gesagt.  mehrere Tonnen für den gleichen realen Gegenstand sind
>>>> ein No-Go und führt zwangsläufig zur Löschung und viel unötig bösem
>>>> Blut.
>>>>         
>>> Sehe ich vom Prinzip her genauso. Es muss aber, wie oben erwähnt,
>>> sichergestellt sein, dass auch Daten, die nicht von der FreienTonne
>>> kommen erhalten bleiben, ansonsten habe ich keine andere Wahl.
>>>       
>> der einzige Tag wo dass ggf. passieren könnte ist "seamark=" weil den
>> beide Schemata benutzen. Ich glaube nich, dass an den änderen Tags von
>> euch irgendwas angerührt wird (genauso wie andere Tags bei von anderen
>> Nodes)
>>     
>
> Nein, ist es nicht. Um beim 29. Juli und im Bereich Fehmarnsund zu bleiben. An 
> diesem Tag wurden von dem User "freietonne-db" folgende Knoten geändert:
>
> Burg 3 (Knoten 431077608) im Changeset 1974102
> Burg 5 (Knoten 431076486) im Changeset 1940649
> Burg 9 (Knoten 431076503) im Changeset 1974088
> heiligenhafen 3  (Knoten 431077562) im Changeset  1974052
> heiligenhafen 7  (Knoten 431077562) im Changeset  1974046
> heiligenhafen 9  (Knoten 431077580) im Changeset  1974038
> heiligenhafen 13  (Knoten 431077531) im Changeset  1974031
>
> In allen Fällen wurden alle vorher bestehenden Informationen gelöscht. Die 
> Änderungen vom User "Jan Jesse" waren OK.
> Mein Fehler, für den ich mich auch aufrichtig entschuldige, war es jetzt 
> anzunehmen, dass dieses Verhalten gewollt ist. Ich hätte auf der Liste 
> detaillierter nachfragen sollen was dort passiert.
> Daher noch einmal mein wirklich freundschaftlicher Aufruf an Jan & Mike: Könntet 
> ihr dort bitte noch einmal hin gucken, ob es nicht wirklich einen Fehler in 
> eurer Software gibt.
>
> Ansonsten sei vermerkt, ich werde ab sofort auf den Schlüssel "seamark=*" 
> verzichten und hoffe auf eine weitere gute Zusammenarbeit,
>   
wie gesagt. Zum Erkennen für deinem Renderstyle brauchst du "seamark" 
als Key nicht aufgeben. Nur bei den Values müssen wir uns entweder 
einigen (wie das vorgeschlagene Schema es handhabt hab ich ja oben 
geschrieben) oder auf einander Rücksicht nehmen (2 values im Renderstyle 
abfragen ist ja jetzt auch kein Hexenwerk). seamark=yes wäre alternativ 
eine salomonische Lösung, is aber die Frage, ob da nicht beide dran 
verloren hätten.
>
> mit besten Grüßen
>
> Olaf
Grüße zurück :)
 Mario