[Talk-de] Routingfähige Garminkarten: Notwendigkeit zur Qualitätssicherung

Florian Lohoff flo at rfc822.org
Di Okt 28 15:15:24 UTC 2008


On Tue, Oct 28, 2008 at 02:10:23PM +0100, Marcus Wolschon wrote:
> Schau im Backlog und schreib mal beides in einer Programmiersprache hin.
> Da hast du einen haufen unscharfer Volltext-Suchen auf großen Datenbeständen
> (is_in) gegenüber einem simplen Polygon-Test den dir ein Abi-Schüler mit
> minimalem Geometrie-Wissen aus dem Kopf runter schreibt.

Volltextsuche!?!? Wo hast du die? Ich sprach von relations da habe ich
einen integer search - ich suche die wayid als member einer relation.
Ich sprach davon alle ways eines Stadtteils als relation mit dem place
zu verknoten ...

> (Stichwort: Anzahl der Schnittpunkte eines Strahls mit den Polygon-Linien
>  muss gerade oder ungerade sein.)

Schnittpunkt? Du meinst contains or overlaps. Und das mit beliebig
bunten polygonen ...


> Ja bis wohin denn?
> Wenn ich wissen will, ob auf einer Straße Tempo 50 gelten, muss ich das
> bis zum Staatsgebiet aufdröseln.

Dieserlei defaults hatten wir in diversen threads eigentlich eine absage
erteilt weil eben eine anzeige eines "geratenen" werts d.h. kein eintrag
eines maxspeeds nicht darauf deutet das dort nichts gilt sondern das
kein mapper bisher was eingetragen hat. Richtig waere das bei
maxspeed=default oder aehnlichem.

Hier waeren die relations aufzudroeseln -> wayid=memberOf(releation) 
und dann der relation kette nach oben.

> > Ich rede nicht von Straßen - is_in auf Straßen halte ich fuer falsch und
> > will die auch nicht korrigieren. Ich rede von place=suburb und groesser.
> 
> und an was hängt dein place=suburb? Und wie ordnest du den
> linken Teil einer Durchgangsstraße eben diesem Stadtteil zu?

place=suburb und groesser haben zum grossteil is_ins und da geht es mir
drum das wenn da was drin steht soll es richtig sein - andernfalls
loeschen oder korrigieren.

Und das Straßenthema wuerde ich eben ueber relations machen ...

> > Straßen zu einer Postleitzahl oder Suburb/City/Village/Hamlet zuzuordnen
> > wuerde ich ueber eine relation loesen. Die ist eindeutig und eindeutig
> > schneller aufzuloesen als ein polygon ...
> 
> Was gegenüber vergessenen Elementen (mal eine neue Kirche eingezeichnet,
> mal eine Straße geteilt,...) genauso fehleranfällig wie is_in. Nein danke.

JOSM fuegt stand heute schon bei teilen von ways beide ways den
entsprechenden relations hinzu - Ist also in JOSM nicht mehr kaputt zu
kriegen. Und die Kirche haengt hoffentlich ja nach Karlsruhe Schema und
einer addr verknuepfung an der Straße oder?

> Wie soll ich denn bitteschön damit die PLZ einer Telephonzelle finden,
> wenn jemand diese Telephonzelle ohne sie in die (dem vorbeifahrenden Mapper
> nicht bekannte) Relation zu packen hingesetzt hat? Auch wenn die Straße daneben
> oder noch eine Straße weiter in der Relation ist, kann ich das nicht
> mehr herausfinden.

Also - du zeichnest eine Telefonzelle ein und da du Ortskundig bist
weisst du die Postleitzahl - da die anderen wege rund um die
Telefonzelle in der relation sind - Weg anwaehlen - relation oeffnen -
telefonzelle anklicken, add selected.

Aber von einzelobjekten - Sprich jedem Kieselstein hat keine geredet. Es
ging um Straßen zur Addresssuche. Und bevor wir nicht fuer jede komische
administrative boundary ein polygon haben wird das der einzige ausweg
sein sowas halbwegs sauber zu loesen.

> Ram brauche ich um dieses eine Relations-Objekt mit den enthaltenen
> Objekt-IDs zu laden?)

4 byte pro object-id? Demnaechst dann vielleicht mal 8.

> sondern, wie eben dargelegt, vermeidbar fehleranfällig.

Aber - solange nicht alle polygone da sind die einzige loesung oder?

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20081028/d4787870/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de