[Talk-de] autobug update

[Florian Lohoff]

On Fri, Nov 07, 2008 at 09:34:41AM +0100, Stefan Dettenhofer (StefanDausR) wrote:
> >
> > Ich weiß noch nicht genau, wie man es genau anwenden sollte, aber
> > diese Liste finde ich irgendwie sympatisch (in dem Rahmen, indem man
> > eine Excel-Tabelle sympatisch finden kann). Auf jeden Fall
> > sympatischer, als diese langen is_in Zeichenfolgen, in denen sich
> > Redundanz und Fehlerteufel um die Vorherrschaft streiten.
> >
> >   
> Hier sehe ich auch das große Problem, dass man nie eine einheitliche 
> Schreibweise vorfinden wird
> > Warum überhaupt muss in dem Tag meines Ortes stehen, in welchem Kreis
> > der Ort ist? Reicht das nicht bei der Stadt, die beim Ort im is_in
> > steht?
> >   
> Ich hatte das (bisher) eigentlich auch als Baumstruktur gesehen, also
> Dorf is_in Gemeinde
> Gemeinde is_in Kreis
> Kreis is_in (Bundes-)Land
> Land is_in Staat
> usw.

Das problem ist das Namen nicht eindeutig sind - So gibt es zig
Neuenkirchen, Neustadt oder Langenberg.

Welches von den vielen is gemeint im is_in?

Alleine mal fuer Langenberg - das ist 3km von mir (Das einzig wahre
Langenberg)

osm=> select * from node_tags where k = 'name' and v like '%Langenberg%' and node_id in (select node_id from node_tags where k like 'place');  node_id  |  k   |       v        
-----------+------+----------------
  60661265 | name | Langenbergheim
  68837412 | name | Langenberg
  69834592 | name | Langenberg
 130788134 | name | Langenberg
 160729255 | name | Langenberg
 240094289 | name | Langenberg
 256058940 | name | Langenberg
 260566325 | name | Langenberg
 298119224 | name | Langenberg

> Damit wurde schon mal eine gewisse fehlerhafte Redundanz wegfallen. 
> Wobei es immer noch Probleme mit gleichnamigen Orten gäbe.

Eben - Orte sind nur mit Namen und is_in pfad eindeutig ...

> Haher bin ich eher der freund eines eindeutigen (und offiziell 
> anerkannten) Schlüssels. Die Gemeindekennzahl wäre da auch möglich, ist 
> aber nur in Deutschland gebräuchlich. Daher kam ich auf die NUTS/LAU.

Koennen wir alles gerne machen - taggst du die 30K places um?

> > Ich gebe zu, ich bin kein großer Freund von Relationen, jedoch sind
> > genau solche Zusammenhänge super in Relationen zu erfassen.
> >   
> Das wäre sicher möglich, nur sehe ich dann das Problem, was man in die 
> Relation aufnimmt: Nur den place= oder auch die Gemeindegrenze oder 
> gleich alle Elemente der Gemeinde?
> Letzteres wäre natürlich nicht sinnvoll zu handeln! So große Relationen 
> sind unbedingt zu vermeiden.
> 
> Wenn man das Problem mit Relationen löst, dann könnte man aber auch 
> gleich auf den NUTS-Schlüssel verzichten bzw. diesen nur als Zusatzinfo 
> an die Relation hängen.
> 
> Ich denke der NUTS/LAU-Schlüssel macht nur Sinn, wenn man den für jedes 
> relevante Element (also insbesondere place=) vergibt. Der ist ja im 
> Prinzip genauso hierarchisch aufgebaut, wie die momentane 
> ausgeschriebene Textform in is_in.
> 
> > Wer also schreibt mal was zum NEUEN Key:NUTS bzw. Key:NUTSLAU ??? Ich
> > denke, derjenige wird Unterstützung bekommen, da es jedem einleuchten
> > sollte, dass wir uns dadurch jede Menge Arbeit ersparen.
> >
> >   
> Mal sehen, was die Diskussion hier noch ergibt (und meine Zeit zulässt)

Genau das mit der Zeit und der Arbeit ist das problem - Solange niemand die
arbeit macht wirds liegenbleiben. Die richtige loesung sind die polygone die
die zugehoerigkeit hoffentlich eindeutig klaeren (Es gibt auch da probleme).

Das is_in gehampel ist nur eine uebergangsloesung bis wir fuer jeden Stadtteil,
Bezirk, Stadt, Kreis, Regierungsbezirk, Bundesland saubere polygone haben.
Bis dahin ist die administrative einordnung der places ein graus ... Also
reparier ich stand heute lieber die is_in und gehe mit einem validator da dran
der gewisse annahmen ueber reihenfolge etc macht so das schreibweise und pfad
fehler eben zutage treten.

Wer es ueber relations loesen moecht - nur zu - finde ich auch keine
schlechte idee.  Nur faengt man da bei 0 an - is_in sind zumindest
halbwegs gepflegt so das man auf einer basisarbeit aufsetzen kann ...

Vor allem kann man das mit den relations parallel machen (genau wie mit
den polygonen) ohne die is_in arbeit zu zerstoeren ...

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/20081107/75952e2f/attachment.sig>