Florian Lohoff schrieb: > On Fri, Oct 24, 2008 at 02:40:23PM +0200, Martin Koppenhoefer wrote: >> Du uebersiehst bei Deiner Kritik, dass die Hausnummern sehr wohl physisch >> existieren, naemlich als Grundstuecke bzw. Haeuser, bzw. Eingaenge, und >> diese sind nicht Teil der Strasse sondern getrennt davon. Von daher habe >> ich ueberhaupt keine Bedenken, mit den Hausnummern wie bisher >> fortzufahren. Schoen waere es aber, die Tags im Editor auf verschiedene >> Layer filtern zu koennen, so dass man sie bei Bedarf z.B. sperren (oder >> sogar ausblenden) kann, und nicht versehentlich Ways verbindet, die >> eigentlich nichts miteinander zu tun haben. > > Das ist mir schon klar das die existieren - aber ob ich mit einem pseudo > pfad neben der Straße die interpoliere (also positionen rate) - oder ob > ich das an die straße klebe ist doch eins oder? >
Vom Routingergebnis her vielleicht schon, allerdings nicht von der Bedeutung her. Obwohl die Daten selbstverständlich prinzipiell benutzbar sein sollen, mappen wir trotzdem nicht für eine bestimmte Anwendung. Nur weil es einem Router vielleicht reicht die Hausnummern direkt an der Straße zu haben, ist für eine andere Anwendung die etwas korrektere Abbildung der Wirklichkeit vielleicht entscheidend. > Mein ziel ist es die Address/Hausnummernpflege zu simplifizieren. Im > moment scheue ich mich ueberhaupt das zu erheben weil die > interpolierende loesung des Karlsruhe Schema einfach ekelig ist. > Findest du. Setzt du Restaurants oder Telefonzellen auch direkt auf die Straße? > Es gibt keinen genauen bezug an welchem Punkt der Straße nun die > Hausnummer ist (und das ist fuer die Navigation das interessante). > D.h. der konverter kann nur raten und 2 rechtwinkelige auf die straße > und den interpolierenden weg konstruieren um dann dem navi zu sagen wo > es denn hinfahren soll. Das ist CPU aufwand der einfach umsonst ist. > Dazu kommt noch das die datenmenge riesig ist und die pflege aufwendig > und unuebersichtlich. > Den CPU Aufwand kann ich nicht beurteilen, allerdings bezweifle ich es, dass es für eine einzelne Adresse (zu mehreren gleichzeitig will man ja selten) so viel ausmacht. Dass man quasi raten muss ist natürlich klar. Andererseits gibt es bei manchen Häusern auch Zugänge von mehreren Seiten, da ist es sowieso fraglich wie man das abbilden soll. > Ich pflege keine Daten fuer die ich nachher nicht eine wirklich sauberere > weiterverarbeitung bzw nutzung sehe. Das ist ein aehnliches problem > wie is_in auf den places. Da das Freitext ist und wir nunmal mehrere > "Langenberg" oder "Neuenkirchen" haben ist das ganze fuer die katz weil > keine zuordnung existiert. Ebenso die nummer mit den flaechenpolygonen > um die Straße den places zuzuordnen - Das ist technisch unsauber und > einfach nur hochwissenschaftliches raten. Daher waere ich fuer Place/is_in > relations die eben die ganzen zugehoerigen Straßen (auch meinetwegen > mehrfach hierarchisch) eindeutig zuordnet. Ja - das mag auf den ersten > blick wie grosser bearbeitungsaufwand aussehen - aber es ist die einzige > saubere technische variante. Mir ist es schleierhaft wie im moment > ueberhaupt die Straßensuche funktionieren kann - Im prinzip ist das > alles nur gerate welche Straße mit dem namen nun "nahe bei" (was ja auch > schon geraten ist) einem Place ist. > Nur ist halt "nahe bei" in Mastholte im umkreis von 300m - Und in Mexiko > Stadt oder Moskau halt auch mal 100km. > Für Relations die Straßen einem Ort zuordnen wäre ich auch, da es einfach schrecklich ist, an jede Straße die PLZ und den Ort zu hängen. Eventuell sollte man auch für die PLZ eine extra Relation verwenden, da ein Ort ja nicht immer nur genau eine PLZ hat. Aber prinzipiell wären solche Relations schon praktisch um die Datenredundanz zu minimieren. Gruß _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
