[Talk-de] is_in Relation für jedes Feature?

Florian Lohoff flo at rfc822.org
So Nov 16 13:44:00 UTC 2008


On Sun, Nov 16, 2008 at 01:44:06PM +0100, Tim Krüger wrote:
> Subject: [Talk-de] is_in Relation für jedes Feature?
> 
> Hallo Mapper!
> 
> Ich komme aus dem Bereich der Navigation und habe daher natürlich auch
> immer ein Augenmark auf die Navigationsfähigkeit der OSM-Daten. Daher
> suche ich nach einer Möglichkeit für jedes Feature anzugeben in welcher
> Gemeinde, welchem Bundesland und Land es liegt (Beispielhaft auf
> Deutschland bezogen).
> Dabei bin ich auf die Relation
> "http://wiki.openstreetmap.org/wiki/Relations/Proposed/Is_In" gestoßen.
> Wenn ich das richtige verstehe ist diese Relation eigentlich nur für
> Flächen in Flächen gedacht. Könnte man dies nicht einfach auch auf
> Straßen, Gebäude, Parkflächen etc. anwenden?
> 
> Viele werden sich jetzt fragen wofür das gut sein soll. Schließlich kann
> man die Zugehörigkeit eines Features zu einer Gemeinde durch die
> Gemeindegrenzen bestimmten. Das stimmt natürlich. Andererseits ist
> Rechenzeit teuer und Speicherplatz billig. Daher würden solche
> Relationen Sinn machen da diese nur einmal angelegt bzw. berechnet
> werden müssten.
> 
> Das möchte ich einfach mal zur Diskussion stellen, um zu sehen was die
> Community davon hält. Falls so etwas schon einmal angedacht war oder es
> schon gibt wäre ich für Informationen sehr dankbar.
> 
> Sollte es so etwas nicht geben, würde ich mich mal an die Arbeit machen
> ein Stück Software zu schreiben das diese Relationen automatisch berechnet!
> 
> Freue mich auf Tipps, Hinweise und eine anregende Diskussion!

Also bisher hat sich OSM immer als sammlung der Basisdaten gesehen. D.h.
fuer die Navigation ist es richtig sind bestimmte sachen so wie sie im
moment geloest sind unbrauchbar z.b. die zugehoerigkeit von objekten zu
polygonen - so ein kleiner OMAP, Freescale oder Nec Vr wird wohl kaum
seine 300mW darauf verbrauchen wollen die 400 Kreis Polygone oder was
auch immer wieviele tausend stadt/gemeindepolygone durchsuchen wollen.
Ist ja auch bloed wenn mal 10 Minuten kein update der Karte stattfindet
nur weil jemand eine Tankstelle sucht ...

Das ganze sollte aber tendentiell nicht in den rohdaten passieren sondern
beim konvertieren der Daten - XML will man der immer zu kleinen CPU ja
eh nicht zumuten. Eine anpassung des Datenformates muss ja eh vorgenommen
werden, warum nicht auch dann einmalig fuer die embedded systeme z.b. die
zugehoerigkeit von Straßen/POIs zu den polygonen vorberechnen.

Ziel sollte es sein die Daten in einem Format zu pflegen das es fuer die
Mapper einfach macht und den aufwand in Grenzen haelt und da sind
Kreis/Stadt/Bundeslandpolygone nun wirklich die einfachste variante.
Das thema is_in relation is ziemlich fehleranfaellig denn jeder der was
an den Daten aendert muss immer dran denken das in die entsprechenden
relations zu packen und wenn man sich mal den pflegezustand der dinge
ansieht die nicht gerendert werden (maxspeed) dann sieht das ziemlich
gruselig aus.

Ein Schritt das ganze mit den Polygonen endlich in einen brauchbaren
zustand zu bringen ist ja der boundary Inspector ...

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/20081116/6a14c289/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de