On Thu, 19 Feb 2009 11:19:12 +0100 (CET), Dirk Stöcker
wrote:
> On Thu, 19 Feb 2009, marcus.wolsc...@googlemail.com wrote:
>
>> Für viele Routing-Alorithmen wie z.B. den Standard "Dijkstra" gibt
>> es kein "Abbiegen von - auf" sondern nur "Weg von A nach B mit Kosten x"
>> und "Weg von B nach D m
On Thu, 19 Feb 2009 11:17:41 +0100, "Marc Schütz"
wrote:
> Deswegen hat er ja auch geschrieben, man sollte an den Algorithmen
arbeiten
> => die Algorithmen ändern.
>
> Ich glaub aber, es geht auch ohne: Man könnte alle relevanten Knoten
(z.B.
> barrier, Kreuzungen/Abzweigungen) als Wegstücke abbi
On Thu, 19 Feb 2009, marcus.wolsc...@googlemail.com wrote:
Für viele Routing-Alorithmen wie z.B. den Standard "Dijkstra" gibt
es kein "Abbiegen von - auf" sondern nur "Weg von A nach B mit Kosten x"
und "Weg von B nach D mit Kosten y".
Das hat mit Winkeln oder der Erkennung was eine Kreuzung ist
> > Dann sollte man aber an den Algorithmen arbeiten. Eine Kreuzung sollte
> > sich doch einfach daran erkennen lassen, ob man 2x ca. 90° abbiegen
> kann
> > oder dazu noch geradeaus oder ähnliches. Daraus könnte man ableiten,
> > dass die Strecke mit dem größeren Winkel einfach "teurer" ist.
>
>
On Wed, 18 Feb 2009 18:20:05 +0100, André Reichelt
wrote:
> marcus.wolsc...@googlemail.com schrieb:
>> On Wed, 18 Feb 2009 12:32:44 +0100, Florian Lohoff
>> wrote:
>>> Mir ist meiner meinung nach mal aufgefallen das die "Penalty" fuer
>>> abbiegen relativ gering ist d.h. es wird bevorzugt durch d
Hallo.
Am Mittwoch, 18. Februar 2009 schrieb André Reichelt:
> Dann sollte man aber an den Algorithmen arbeiten. Eine Kreuzung sollte
> sich doch einfach daran erkennen lassen, ob man 2x ca. 90° abbiegen kann
> oder dazu noch geradeaus oder ähnliches. Daraus könnte man ableiten,
> dass die Strecke
marcus.wolsc...@googlemail.com schrieb:
> On Wed, 18 Feb 2009 12:32:44 +0100, Florian Lohoff wrote:
>> Mir ist meiner meinung nach mal aufgefallen das die "Penalty" fuer
>> abbiegen relativ gering ist d.h. es wird bevorzugt durch die engen
>> gassen zu kurven anstatt 50m mehr drumherum zu fahren .
On Wed, 18 Feb 2009 12:32:44 +0100, Florian Lohoff wrote:
> On Wed, Feb 18, 2009 at 11:58:24AM +0100, Dirk Stöcker wrote:
>> Zwei Sachen die mir immer wieder auffallen:
>> 1) ORS bevorzugt im Fastest-Modus immer noch kurze Strecken:
>>
>> Z.B.
>>
http://data.giub.uni-bonn.de/openrouteservice/ind
On Wed, Feb 18, 2009 at 11:58:24AM +0100, Dirk Stöcker wrote:
> Zwei Sachen die mir immer wieder auffallen:
> 1) ORS bevorzugt im Fastest-Modus immer noch kurze Strecken:
>
> Z.B.
> http://data.giub.uni-bonn.de/openrouteservice/index.php?start=14.1822771,51.1260447&end=14.183189,51.1298759&pref=F
On Wed, 18 Feb 2009, Pascal Neis wrote:
Hi,
wie in letzter Woche angekündigt ist eine neue Version der
Webseite von ORS online (thx to peter). Dabei wurde die
Oberfläche etwas aufgeräumt und ein besseres Handling von
Start-, Via und Zielpunkt realisiert. Daneben können jetzt diese
Punkte auch üb
Pascal Neis wrote:
> Weiterhin ist seit gestern Nachmittag noch ein neuer Service
> online, der zu einer berechneten Route ein Höhenprofil erstellt.
Wird das beim Fahrrad- und/oder Fußgängerrouting berücksichtigt?
Insbesondere mit dem Fahrrad ist das ja nicht unerheblich, ob man 5km
außenrum o
Marc Schütz wrote:
> Hatto schrieb:
>> Zur vereinfachten Demo habe ich hier einmal den Weg von der echten
>> Position des Adress-Nodes zu der mit der Suche ermittelten Position "Im
>> Weidenbruch 46, Köln" verlinkt:
>>
http://data.giub.uni-bonn.de/openrouteservice/index.php?start=7.0278436,50.9799
> Aufgefallen ist mir auch etwas im Fall, dass die addr:street sich vom Namen
> der nächstliegenden Straße unterscheidet. Da wird der nächste Punkt der
> namensgleichen Straße und nicht einer auf der nächstliegenden Straße
> genommen. Das mag manchmal sinnvoll sein; aber zum Beispiel bei "Im
> Weid
Pascal Neis wrote:
> wie vielleicht verschiedene von euch bereits mitbekommen haben
> gibt es zwei Neuerungen auf OpenRouteService.org (ORS).
Was mir noch auffiel: Bei meinen Tests des Fußgänger- und Fahrradroutings
verwirrt mich derzeit, dass es (bei der Anzeige mit mapnik) manche blauen
Rad- bz
christof.amelun...@sbg.ac.at wrote:
> Hatto von Hatzfeld schrieb:
>> Man könnte doch ein fakultatives Trennzeichen verwenden ("Frankfurt; Am
>> Mainufer 13"), an dem sich die Suchfunktion dann orientieren könnte.
[...]
> Trotzdem "hilfst" du dem Service, wenn du ein Komma als Trennzeichen
> benut
Hi Marco,
Marco Horstmann schrieb:
>>> Wenn ich "Barenburg Am Sportplatz" suche dann findet er Barenburg nicht,
>>> sondern nen Ort Namens "(AT) Am Sportplatz ".
>>>
>> Da hast du leider zufällig einen ziemlich blöden Fall erwischt ;-)
>> Das Problem ist hier, dass es im OSM keine Stadt name
christof.amelun...@sbg.ac.at schrieb:
> Hi Marco,
>
> Marco Horstmann schrieb:
>
>> Ich habe grade mal rumprobiert.
>>
>> Also wenn ich nur Barenburg als Ziel suche, dann findet er es wie du es
>> beschrieben hast.
>>
>> Wenn ich "Barenburg Am Sportplatz" suche dann findet er Barenburg nicht,
Hi Marco,
Marco Horstmann schrieb:
> Ich habe grade mal rumprobiert.
>
> Also wenn ich nur Barenburg als Ziel suche, dann findet er es wie du es
> beschrieben hast.
>
> Wenn ich "Barenburg Am Sportplatz" suche dann findet er Barenburg nicht,
> sondern nen Ort Namens "(AT) Am Sportplatz ".
Da
Hallo Hatto,
danke erstmal für die Anregungen!
Hatto von Hatzfeld schrieb:
> Eine grundlegende Frage habe ich zu der Suchfunktion: Erhöht es nicht das
> Fehlerpotential, wenn Ortsname und Straße prinzipiell ohne Trennungszeichen
> eingegeben werden müssen ("Frankfurt Am Mainufer 13" u.ä.)? Man kö
Pascal Neis wrote:
> Durch die "Unscharfe"-Suche sollten Schreibfehler im Stadt-
> oder Straßennamen bis zu einem gewissen Grad keine Auswirkungen bei
> der Suche verursachen.
Wie alle anderen hier, die sich geäußert haben, bin ich sehr angetan von den
neuen Features. Ich will das hier deutlich
Florian Lohoff schrieb:
> On Thu, Jan 15, 2009 at 11:45:36AM +0100, Pascal Neis wrote:
>> Die zweite Neuigkeit betrifft den Geocoder von ORS. Zum einen wurde
>> die Performance verbessert und eine "unscharfe"-Suche (Fuzzy-Search)
>> implementiert. Durch die "Unscharfe"-Suche sollten Schreibfehler i
Hi,
> Hallo,
> vielen Dank mal wieder, dass k?nnte die Hausnummererfassung stark
> steigern :)
> Mir sind aber auch noch ein paar komische Dinge bei der neuen Suche
> aufgefallen.
> Wenn ich z.B. nach "Immenrode" suche findet er:
> 1. (DE) 38690Immenrode (Niedersachsen)
> 2. (DE) 99735Immenrode (Th
Hallo,
vielen Dank mal wieder, dass könnte die Hausnummererfassung stark
steigern :)
Mir sind aber auch noch ein paar komische Dinge bei der neuen Suche
aufgefallen.
Wenn ich z.B. nach "Immenrode" suche findet er:
1. (DE) 38690Immenrode (Niedersachsen)
2. (DE) 99735Immenrode (Thüringen)
das ist sch
Hallo Christof,
ich habe "Barenburg Am Sportplatz" als Routing Ziel gesucht.
Ich habe grade mal rumprobiert.
Also wenn ich nur Barenburg als Ziel suche, dann findet er es wie du es
beschrieben hast.
Wenn ich "Barenburg Am Sportplatz" suche dann findet er Barenburg nicht,
sondern nen Ort Namen
Hallo Pascal,
ich fänd auch klasse wenn es möglich ist ab einer bestimmten Länge der
Eingabe eine Auflistung der
Möglichkeiten zu machen. z.B. haben ich Barenburg meinem Heimatdorf
gesucht und nicht gefunden.
Es fiel mir dann ein, dass irgendjemand Barenburg als "Barenburg bei
Sulingen" eingep
On Thu, Jan 15, 2009 at 09:05:06PM +0100, Florian Lohoff wrote:
> Hi,
>
> On Thu, Jan 15, 2009 at 11:45:36AM +0100, Pascal Neis wrote:
> > Die zweite Neuigkeit betrifft den Geocoder von ORS. Zum einen wurde
> > die Performance verbessert und eine "unscharfe"-Suche (Fuzzy-Search)
> > implementiert.
Hi,
On Thu, Jan 15, 2009 at 11:45:36AM +0100, Pascal Neis wrote:
> Die zweite Neuigkeit betrifft den Geocoder von ORS. Zum einen wurde
> die Performance verbessert und eine "unscharfe"-Suche (Fuzzy-Search)
> implementiert. Durch die "Unscharfe"-Suche sollten Schreibfehler im Stadt-
> oder Straßenn
Hi Chris,
Chris-Hein Lunkhusen schrieb:
> Pascal Neis schrieb:
>
>> Weiterhin werden jetzt auch Hausnummern bei der
>> Suche verwendet (soweit in OSM vorhanden!).
>
> hab es gerade mal getestet. Es reicht anscheinend nicht wenn
> NUR der addr:housenumber Tag vorhanden ist?
> Es muss auch der ad
Pascal Neis wrote:
> Hi,
> wie vielleicht verschiedene von euch bereits mitbekommen haben
> gibt es zwei Neuerungen auf OpenRouteService.org (ORS).
>
> Seit Ende Dezembers letzten Jahres werden Zwischenpunkte (Via-Punkte)
> bei einer Routenplanung nicht mehr nur vom RouteService selbst sondern
> a
Moin,
> Seit Ende Dezembers letzten Jahres werden Zwischenpunkte (Via-Punkte)
> bei einer Routenplanung nicht mehr nur vom RouteService selbst sondern
> auch auf der Webseite unterstützt. (thx Peter)
oh Mann, ist das geil!
:)
Gruß,
ce
___
Talk-de ma
On Thu, Jan 15, 2009 at 11:45:36AM +0100, Pascal Neis wrote:
> Die zweite Neuigkeit betrifft den Geocoder von ORS. Zum einen wurde
> die Performance verbessert und eine "unscharfe"-Suche (Fuzzy-Search)
> implementiert. Durch die "Unscharfe"-Suche sollten Schreibfehler im Stadt-
> oder Straßennamen
On Thu, 15 Jan 2009 12:01:05 +0100, Chris-Hein Lunkhusen
wrote:
> Pascal Neis schrieb:
>
>> Weiterhin werden jetzt auch Hausnummern bei der
>> Suche verwendet (soweit in OSM vorhanden!).
>
> Hi Pascal,
> hab es gerade mal getestet. Es reicht anscheinend nicht wenn
> NUR der addr:housenumber Tag
Pascal Neis schrieb:
> Weiterhin werden jetzt auch Hausnummern bei der
> Suche verwendet (soweit in OSM vorhanden!).
Hi Pascal,
hab es gerade mal getestet. Es reicht anscheinend nicht wenn
NUR der addr:housenumber Tag vorhanden ist?
Es muss auch der addr:street Tag existieren?
Da muss ich mein W
33 matches
Mail list logo
