[Talk-at] burgenländische Landesstraßen

Stefan Tauner stefan.tauner at gmx.at
Sun Jan 6 16:37:12 UTC 2013


On Sun, 06 Jan 2013 17:02:18 +0100
Jimmy_K <Jimmy_K at gmx.at> wrote:

> Am 06.01.2013 16:14, schrieb Stefan Tauner:
> 
> > redundante tags sind auf lange zeit äußerst kontraproduktiv, wenn ihr
> > zweck nicht eindeutig erkennbar ist (ggfs ein source oder sonstiger tag
> > dabei steht), weil man sie nicht von "echten" einträgen (automatisch)
> > unterscheiden kann. insofern ist das löschen dieser redundanten
> > information nicht "unverschämt" sondern eine verbesserung der daten
> > IMHO (und ich halte das bei vergleichbaren sachen ähnlich).
>
> Wenn er "meine" Daten gelöscht hätte, dann wäre ich ordentlich
> angepisst. Ist aber zum Glück nicht der Fall. Ich lese zwar doch das
> Meiste in Forum und ML, aber dass die 100 Überland nicht eingetragen
> werden ist mir gänzlich neu, somit habe ich es auch bis jetzt getan.
> (Weiß noch nicht wie ich weiter verfahre)

es gibt keine daten "anderer". das sind alles unsere daten. wir sind
alle für sie verantwortlich und sie gehen uns auch alle etwas an. das
ist die grundlage der lizenz und der große vorteil wie auch ein großes
konfliktpotential (offensichtlich :)
daß sich mapper mit den von ihnen eingetragenen daten identifizieren,
ist zwar menschlich und eine enorme motivation zum mappen, aber
verdrängt auch oft den teilenden, sozialen aspekt des projekts. das muß
man sich immer wieder vor augen führen bei solchen diskussionen, mir
gehts da nicht anders.

> 
> Ich versuche mich kurz zu fassen:
> 
> -) Daten von anderen Löschen, weil sie mal Probleme machen KÖNNTEN? Wäre
> es da nicht sinnvoller die Daten mit einem fixme zu versehen und falls
> das Wunder geschieht und in Österreich die vmax tatsächlich auf 80 oder
> 90 gesenkt wird, dann überlegen wie mit den Daten weiter verfahren wird?
> Oder falls es aufgrund der Redundanz wirklich mal Probleme gibt, könnte
> ein bot losgelassen werden.

das ist ja genau der (mein) punkt: eindeutig machen von wirklicher
beschilderung und impliziter regelung. ich habe keine ahnung, ob es in
wirklichkeit redundante beschilderung gibt (sprich ob irgendwo 100er
schilder stehen, obwohl das sowieso klar ist... hab keinen
führerschein ;), aber es würde mich nicht wundern. selbst wenn das
nicht so ist, besteht das problem, daß man sofort bei einer änderung
einen bot am start haben muß, da ansonsten mapper anfangen die neuen
gegebenheiten zu mappen und man dann wieder nicht weiß, was gemeint
ist/war...

> […]
> 
> -) Ich finde das Eintragen von maxspeed=50 + source:maxspeed=rural
> aufgrund von Satellitenbilder viel Gefährlicher als irgendwelche
> Redundanzen! Es erweckt den Eindruck, dass die Straßen schon ordentlich
> getagged wurden, dabei wurde nur geschätzt. (Ich kann von einem Luftbild
> innerhalb der Ortsgebiete in meiner Umgebung nicht erkennen, ob dort 30
> oder 70 erlaubt sind, was es hier alles gibt). Das ist vortäuschen von
> Daten, mit welcher Motivation auch immer...

da sind wir uns einig, war aber mWn nicht thema dieses threads.

> -) Was für mich aktuell FÜR ein maxspeed=100 spricht ist, dass wenn
> Router auf Strecken ohne maxspeed von zulässigen 100 km/h ausgehen,
> kommt es in manchen Gebieten zu gigantischen Berechnungsfehler, wenn es
> nur Ortsgebiet wäre. Falls die 100 weiter eingetragen werden, könnte der
> Router bei nicht mit einem maxspeed versehenen Straßen von 60-70 km/h
> ausgehen und das Ergebnis wäre trotzdem halbwegs passend. (Sehe ich
> nicht als Taggen für den Router/Render/etc., da ich ja keine Tags
> verbiege, damit etwas wo besser aussieht, funktioniert, etc.)

man muß das maxspeed ja nicht zwingend entfernen, solange es stimmt.
man könnte einen zusätzlichen tag adden, damit es eindeutig wird, daß
es nicht explizit ausgeschildert ist (source:maxspeed bietet sich an,
aber im grunde ist es vollkommen wuarscht, solange es sicher
durchsetzt :)

ps: wieso verwenden wir das place eigentlich dermaßen anders, als alle
anderen?
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner




More information about the Talk-at mailing list