Hi,
Martin Koppenhoefer wrote:
> Diese leidige Diskussion ueber das Karlsruhe-Schema nervt ein bisschen, da
> bisher noch kein Fall aufgezeigt wurde, wo das Schema nicht funktioniert,
> und es wohl kaum eine einfachere Loesung gibt, als einfach jede Nummer mit
> einem Node zu repraesentieren (eine
On Tue, Oct 28, 2008 at 01:23:14PM +0100, Martin Koppenhoefer wrote:
>nein, ist richtig. Steht uebrigens auch genauso in der Berliner
>Numerierungsverordnung (kann ich mir nicht verkneifen, da Du Berlin als
>Beispiel zitierst):
>http://www.berlin.de/ba-spandau/verwaltung/gesetze/nrv
Am 28. Oktober 2008 13:10 schrieb Marcus Wolschon <[EMAIL PROTECTED]>:
> Am 28. Oktober 2008 11:59 schrieb Birgit Nietsch <[EMAIL PROTECTED]>:
> > Hausnummern sind keine Hausnummern sondern Grundstücksnummern,
> > und sind Attribute der Grundstücke, die neben der Straße liegen.
>
> Schlichtweg Fal
Am 28. Oktober 2008 11:59 schrieb Birgit Nietsch <[EMAIL PROTECTED]>:
> Hausnummern sind keine Hausnummern sondern Grundstücksnummern,
> und sind Attribute der Grundstücke, die neben der Straße liegen.
Schlichtweg Falsch.
Deine Konstruktion fällt bereits bei mehreren Eingängen pro
Gebäude (habe ic
Florian Lohoff schrieb:
> Das argument das Hausnummern kein attribut der straße sind ist
> richtig. Aber genausowenig sind sie attribut eines ways der neben
> der straße liegt. Und nach dem Motto das wir nur mappen in form
> von nodes und ways was physich existiert (siehe diskussion um
> fluglinie
Florian Lohoff schrieb:
> So wie ich diverse mails bereits auf talk und dev interpretiert
> habe gibt es auch ausserhalb Deutschlands die mit dem Karlsruhe
> schema nicht klarkommen. Ich meine da mails aus Indien gesehen zu
> haben.
Das liegt möglicherweise an der etwas exotischen Einordnung
des
Florian Lohoff schrieb:
> On Sat, Oct 25, 2008 at 05:36:02PM +0200, Frederik Ramm wrote:
>> Es passt halt nicht so recht, wenn man jedes einzelne Haus als Gebaeude
>> erfasst - und das tun wir -, dann aber bei den Hausnummern auf
>> Interpolation setzt. Aber zugegben - Die Hausnummern kommen halt
On Sat, Oct 25, 2008 at 05:36:02PM +0200, Frederik Ramm wrote:
> Es passt halt nicht so recht, wenn man jedes einzelne Haus als Gebaeude
> erfasst - und das tun wir -, dann aber bei den Hausnummern auf
> Interpolation setzt. Aber zugegben - Die Hausnummern kommen halt nicht
> vom Luftbild, daher
Hallo,
Florian Lohoff wrote:
> Und der Aufwand von Straßennetz zu erfassen zu Straßen + Interpolierte
> Hausnummern ist vermutlich irgendwas mit 1:10. Wenn wir jetzt noch JEDE
> Hausnummer einzeln aufnehmen und einen genauen punkt zuordnen ist man
> nochmal bei 1:10.
Es passt halt nicht so recht,
On Fri, Oct 24, 2008 at 07:43:11PM +0200, Sebastian Hohmann wrote:
> Allerdings kommt es ja darauf an wo man wohnt. In Gegegenden die gut
> erfasst sind und viele Mapper haben, werden sicher auch Hausnummern
> schneller und detaillierter erfasst.
>
> Aber es stimmt wohl schon, dass meistens eine
Florian Lohoff schrieb:
> On Thu, Oct 23, 2008 at 11:02:27PM +0200, Sebastian Hohmann wrote:
>> Besser daran ist, dass Häuser nunmal neben der Straße liegen und wir
>> versuchen die Wirklichkeit vereinfacht abzubilden. Zudem ist es noch
>> konsistent zu POIs wie Geschäften oder Restaurants die au
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 sonder
On Thu, Oct 23, 2008 at 11:02:27PM +0200, Sebastian Hohmann wrote:
> Besser daran ist, dass Häuser nunmal neben der Straße liegen und wir
> versuchen die Wirklichkeit vereinfacht abzubilden. Zudem ist es noch
> konsistent zu POIs wie Geschäften oder Restaurants die auch neben der
> Straßen einge
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 h
>
> Ein weitere punkt weshalb ich eine partial way relation bevorzuge ist
> das ich das interpolationsschema Karlsruhe sowas von Schei*** finde. Mit
> einem mal tauchen in den daten ways auf die gar nicht physisch
> existieren und das zeugs ist einfach nur unuebersichtlich. Ein
> vorschlag hier mit
Florian Lohoff schrieb:
> On Thu, Oct 23, 2008 at 06:41:50PM +0200, Sebastian Hohmann wrote:
>> Florian Lohoff schrieb:
>>> Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben
>>> jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar
>>> interpolierte hausnummern geben will i
On Thu, Oct 23, 2008 at 06:41:50PM +0200, Sebastian Hohmann wrote:
> Florian Lohoff schrieb:
> > Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben
> > jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar
> > interpolierte hausnummern geben will ist overkill. Dazu kommt ja
Florian Lohoff schrieb:
> Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben
> jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar
> interpolierte hausnummern geben will ist overkill. Dazu kommt ja noch
> das Dogma das nur physisch existentes gemappt werden soll. Dieser
>
Dirk Stöcker wrote:
On Wed, 22 Oct 2008, Florian Lohoff wrote:
Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle
den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen
Endpunkt
teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen
Weg betrach
On Wed, Oct 22, 2008 at 07:08:09PM +0200, Dirk Stöcker wrote:
> Das das praktisch so ist stimmt. Aber wenn Du theoretisch herangehst, dann
> habe ich Weg1 - Über-Knoten - Weg2. Das kaum Fälle vorstellbar sind, wo
> die Knoten nicht zu Weg1 und Weg2 gehört ist richtig, aber theoretisch
> eben vor
On Wed, 22 Oct 2008, Florian Lohoff wrote:
Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das
das nicht die schoenste loesung ist - aber sie ist etabliert.
Nein. Hier ist ein großer Unterschied. Die Turn-Relations nutzen einen
Knoten als Teil der Relation. Sie nutzen kein
On Wed, Oct 22, 2008 at 06:38:52PM +0200, Dirk Stöcker wrote:
> >Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das
> >das nicht die schoenste loesung ist - aber sie ist etabliert.
>
> Nein. Hier ist ein großer Unterschied. Die Turn-Relations nutzen einen
> Knoten als Teil d
On Wed, 22 Oct 2008, Florian Lohoff wrote:
dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu
suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die
Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht
sofort einsichtig ist, dass diese H
On Wed, Oct 22, 2008 at 06:03:19PM +0200, Dirk Stöcker wrote:
> On Wed, 22 Oct 2008, Florian Lohoff wrote:
>
> >>Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle
> >>den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt
> >>teilen, dann kann ich diese zu
On Wed, 22 Oct 2008, Florian Lohoff wrote:
Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle
den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt
teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen
Weg betrachten. An Kachelgrenzen m
On Wed, Oct 22, 2008 at 04:52:24PM +0200, Florian Lohoff wrote:
> Es geht mir ueberhaupt nicht ueber das rendering sondern darum das
> bestimmte attribute im moment nicht zu modellieren sind. So sind
> vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige
> geschwindigkeitsbeschraenkungen,
On Wed, Oct 22, 2008 at 04:56:12PM +0200, Dominik Spies wrote:
> > Beispiel:
> >
> > |--| Way Beispielstraße ref K1
> > || Geschwindigkeit 80
> > |---| Fahrradweg links
> > |---|
2008/10/22 Florian Lohoff <[EMAIL PROTECTED]>:
> On Wed, Oct 22, 2008 at 04:24:03PM +0200, Dominik Spies wrote:
>> Hallo,
>>
>> > Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle
>> > nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via
>> > relations drank
On Wed, Oct 22, 2008 at 04:25:13PM +0200, Dirk Stöcker wrote:
> So einfach ist das nicht. Die bisherige Methode Wege in Abschnitte zu
> teilen sieht vielleicht nicht so schön aus, ist algorithmisch aber leicht
> zu verarbeiten. Wenn die Renderer sich endlich mal bequemen
> würden zusammengehörig
On Wed, Oct 22, 2008 at 04:24:03PM +0200, Dominik Spies wrote:
> Hallo,
>
> > Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle
> > nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via
> > relations dranknoten d.h.
> >
> > Unidirektionale geschwindigkeitsbe
On Wed, 22 Oct 2008, Florian Lohoff wrote:
Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle
nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via
relations dranknoten d.h.
Wunderbar. Statt also den Weg in zwei Teile zu teilen willst Du unzählige
Relatio
Hallo,
> Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle
> nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via
> relations dranknoten d.h.
>
> Unidirektionale geschwindigkeitsbeschraenkungen:
>
>type=speedlimit
>from=nodeidA
>to=n
On Wed, Oct 22, 2008 at 03:34:48PM +0200, Dirk Stöcker wrote:
> Subject: Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise
> attribute/tags Was: Fahrradspur
>
> On Wed, 22 Oct 2008, Florian Lohoff wrote:
>
> >Ich wuerde halt den way gar nicht mehr unterbrechen wolle
On Wed, 22 Oct 2008, Florian Lohoff wrote:
Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle
nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via
relations dranknoten d.h.
Wunderbar. Statt also den Weg in zwei Teile zu teilen willst Du unzählige
Relati
On Wed, Oct 22, 2008 at 01:34:58PM +0200, Birgit Nietsch wrote:
> Solche Fleißarbeit ist auch anderswo zu beobachten, und das finde
> ich furchtbar. Vor lauter separaten Radspuren, Busspuren,
> Bebauungsdaten landen wir bei einem Gewirr von parallelen Linien,
> das man beim Bearbeiten kaum mehr aus
35 matches
Mail list logo