Turning Restrictions

17 views
Skip to first unread message

María Arias de Reyna

unread,
Jan 27, 2012, 6:11:47 AM1/27/12
to mona...@googlegroups.com
Hi there!

I'm trying to execute the turn-contract branch of monav, but I have some issues I don't know how to solve. I know this is an experimental feature and can have bugs, but I am trying to run it at least once to see how it works.

First of all, when I execute the MoNavP (processor) application, I have to pass some arguments to get the contractionhierarchiesturn plugin work, like "--cht-contract --cht-plain-query --cht-query --edge-create --edge-contract". I found this arguments looking through the source code, but I don't know where can I read some documentation about them. Are they optional or should I use all of them always? Am I missing some other essential argument?

Also, I have found some asserts that break the execution. For example, on line 491 of plugins/contractionshierarchiesturn/turnquery.h there is a 
assert( source.source < m_graph.GetNumberOfNodes() );
which fails and I'm not quite sure if it should fail. I mean: what if the number of nodes on the graph is lower than the id of the source edge? Or am I missing something about the meaning of this assert?

If I comment that assert (and some asserts more of the same type) I end up on a segmentation fault, so I guess they should be useful somehow. Any hint about its use or meaning?

Maybe I'm having all this issues because the source data. I have used spain.osm and andalucia.osm. Do you know any .osm which works well with this algorithm?

Thanks and congrats for the project, it feels really good (at least the non-turning part)!

María Arias de Reyna

unread,
Jan 27, 2012, 7:02:09 AM1/27/12
to mona...@googlegroups.com
El día 27 de enero de 2012 12:11, María Arias de Reyna
<del...@gmail.com> escribió:

> Hi there!
>
> I'm trying to execute the turn-contract branch of monav, but I have some
> issues I don't know how to solve. I know this is an experimental feature and
> can have bugs, but I am trying to run it at least once to see how it works.
>
> First of all, when I execute the MoNavP (processor) application, I have to
> pass some arguments to get the contractionhierarchiesturn plugin work, like
> "--cht-contract --cht-plain-query --cht-query --edge-create
> --edge-contract". I found this arguments looking through the source code,
> but I don't know where can I read some documentation about them. Are they
> optional or should I use all of them always? Am I missing some other
> essential argument?

I am trying to execute it with only certain arguments. I have found
that if I use only "--edge-create --edge-contract", it apparently
works well, but the client fails to understand it. That means: it
appears on red and the load says "Could Not Load Map Data".

Also, to compile the client I had to add the turn plugin to the .pro
file (plugins/client_plugins.pro).

--
María Arias de Reyna Domínguez
Área de Aplicaciones
Emergya Consultoría
Tfno: +34 954 51 75 77 / +34 607 43 74 27
Fax: +34 954 51 64 73
www.emergya.es

JohnK

unread,
Jan 28, 2012, 9:56:58 PM1/28/12
to MoNav-dev
Hi, Maria

I guess the source.source should be the one endpoint node-ID of source-
edge.
So, the below assertion should be check whether the node-ID is valid.
assert( source.source < m_graph.GetNumberOfNodes() );
Obviously, this node-ID should be lower than than total nodes number.

In the query consider turn cost, actually the shortest path query is
between 2 edges.
So elements in Priority Queue should remember the node and edge both.

Maria Arias de Reyna

unread,
Jan 30, 2012, 4:03:30 AM1/30/12
to mona...@googlegroups.com, JohnK
El Domingo, 29 de enero de 2012, JohnK escribió:
> Hi, Maria

Hi John,

> I guess the source.source should be the one endpoint node-ID of source-
> edge.
> So, the below assertion should be check whether the node-ID is valid.
> assert( source.source < m_graph.GetNumberOfNodes() );
> Obviously, this node-ID should be lower than than total nodes number.

Thanks for your answer. Do you think that it does mean that the importer is
skipping some step and is not reordering the nodes?

> In the query consider turn cost, actually the shortest path query is
> between 2 edges.
> So elements in Priority Queue should remember the node and edge both.

That makes total sense.

Thank you very much.

--
María Arias de Reyna Domínguez

Área de Operaciones

Emergya Consultoría
Tfno: +34 954 51 75 77 / +34 607 43 74 27
Fax: +34 954 51 64 73

www.emergya.com

JohnK

unread,
Jan 30, 2012, 9:31:26 PM1/30/12
to MoNav-dev


On 1月30日, 下午5时03分, Maria Arias de Reyna <mar...@emergya.com> wrote:
> El Domingo, 29 de enero de 2012, JohnK escribió:
>
> > Hi, Maria
>
> Hi John,
>
> > I guess the source.source should be the one endpoint node-ID of source-
> > edge.
> > So, the below assertion should be check whether the node-ID is valid.
> > assert( source.source < m_graph.GetNumberOfNodes() );
> > Obviously, this node-ID should be lower than than total nodes number.
>
> Thanks for your answer. Do you think that it does mean that the importer is
> skipping some step and is not reordering the nodes?

I am sorry. I don't know the exact procedure of Monav with turn cost.

Christian Vetter

unread,
Feb 2, 2012, 6:55:09 AM2/2/12
to mona...@googlegroups.com
Hi,

The turn cost branch is currently not working and-to-end, and was only
used to run benchmarks / sanity tests for this proof-of-concept /
prototype.

Therefore we do not support this branch at the moment ( and until a
proper version is reintegrated into default ), I am sorry to
disappoint you there.

We have skipped on this task so far, since turn restrictions are few
in OSM data and the changes would entail an increase in map data.

Best regards,

Christian

Maria Arias de Reyna

unread,
Feb 2, 2012, 7:00:10 AM2/2/12
to mona...@googlegroups.com, Christian Vetter
El Jueves, 2 de febrero de 2012, Christian Vetter escribió:
> Hi,

HI Christian,


>
> The turn cost branch is currently not working and-to-end, and was only
> used to run benchmarks / sanity tests for this proof-of-concept /
> prototype.
>
> Therefore we do not support this branch at the moment ( and until a
> proper version is reintegrated into default ), I am sorry to
> disappoint you there.

Thank you very much for your answer. After reading carefully the papers, I
understood much better what was the code, but was unable to fully run it.

> We have skipped on this task so far, since turn restrictions are few
> in OSM data and the changes would entail an increase in map data.

Anyway, congratulations for the project and the research. It has been very
helpful.

> Best regards,
>
> Christian

Regards,
María.

Reply all
Reply to author
Forward
0 new messages