the basis of
this input GPS track?
This "most likely valid route" is then returned to you. It can have more
or fewer points than the input geometry; in fact matching input geometry
points to certain points on the output will be very difficult!
Bye
Frederik
--
Frederik Ramm ## eMail
Or, what Julien said ;)
On 26.08.20 10:31, Frederik Ramm wrote:
> Hi,
>
> On 26.08.20 03:29, Alex Valencia wrote:
>> So I was thinking if there is a proper way to achieve this goal. We
>> are considering separating the matrix calculation over the map in a
>> se
;avoids class A". This feature is documented here
https://github.com/Project-OSRM/osrm-backend/issues/4006
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@open
aware of any benefits (even if you *were*
running several routing engines on the same server using the same
routing graph, which also is not something that makes sense to me).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09"
he search engine
with every request - waste of time and resources.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
something roughly similar, I could probably take
it from there. Else I'd have to hold a separate copy of the routing
graph for this and that would seem a waste!
Best
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
_
ed to find an optimal
solution, or could there be freak cases where a sub-optimal solution is
returned?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@ope
144 GB of
RAM.
Also if it is important for you to switch to a new data version without
a production interruption of a few minutes, you need enough RAM to hold
the routing graph twice.
Best
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09"
were more important for me than fast routing times...?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
Hi,
On 10/07/2016 09:43 AM, Frederik Ramm wrote:
> I have finished bisecting the commits and ended up with
> 2b466b2fb29c416149b4d881c151349218a63e1e as the first bad commit -
> everything before that works, everything after that segfaults. I'll have
> a closer look.
I'm afrai
Hi,
On 10/06/2016 09:28 PM, Frederik Ramm wrote:
>so all OSRM releases up to 5.2.7 work ok on my machine and with my
> input file and the foot profile; all releases from 5.3.0 upwards have
> the segfault. I'll continue trying to identify exactly where it was
> introduced.
I h
file that somehow triggers the segfault, I haven't tried other
environments yet.)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@openstreetmap
ed Europe file to see what happens. Any other ideas
are welcome.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
port some IOCTL
operation or so that STXXL wants to use. I ended up creating a sparse
200 GB file on the ram disk and loopback-mounting that to put an ext4
file system on it, just to enable STXXL to put its swap file there.
Surely better approaches exist?
Bye
Frederik
--
Frederik Ramm ## eMail fre
n node, then
turning from one onto the other is not possible. Carelessly "noding"
such an intersection would break routing for OSM.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
OSRM-t
that many.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
16 matches
Mail list logo
