Android Brouter app 1.7.0 do not calculate the right route

[LupinSun]

It seems that these parameters while changing them do not affect the calculation: assign downhillcost; assign downhillcutoff, assign uphillcost, assign uphillcutoff I tryed as external app combine with locus map, and seems that locus map offline calculation have same problem, obviously tested same profile I attached here, no problem with the old version 1.6.3 Enduro v3 initial.zip

[quaelnix]

@LupinSun, my fault, I did not add enough zeros in line 308:

Technically, values >= 10000 for a (way-)costfactor, and >= 1000000 for a nodes "initalcost" are treated as infinity, so please use these as the "forbidden" values.

assign gatepenalty switch and access= Unknown_Gate 0 100000

needs to be:

assign gatepenalty switch and access= Unknown_Gate 0 1000000

[LupinSun]

assign gatepenalty switch and access= Unknown_Gate 0 1000000

I had already assigned this value and even higher ones but the route keeps going through this gate, maybe because the gates has the tag motorcycle=yes?

[quaelnix]

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

[LupinSun]

I

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

ok, very clear, now I understand how it works

[LupinSun]

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

Unfortunately I could never wanted writing to you again but unfortunately some tick still don't work as they should. When I select Unknown_Gate, the calculated route could pass through all those gates that do not have the specific "motorcycle=yes" tag, while when I untick, it must not pass through all those gates that do not have the specific "motorcycle=yes" tag, but at the same time the route could pass through all those gates where "motorcycle=yes" is present, while if I tick No_Gate, the route, regardless of the type of tag, must not be able to pass through any gate. Obviously I've already tried to make some changes before writing to you but I can't solve it definitively. look at these two gates, one does not have the motorcycle tag but a generic _motorvehicle (the one at the start), while the other at the end has the specific motorcycle=yes tag. Saddly in this profile it doesn't happen, the route have no changes if I untick Unknown_gate, the gate at the start must be "jump" if I untick, and the one at the end unchanged: http://148.251.191.149/brouter-web/#map=17/40.08722/9.03471/standard&lonlats=9.056783,40.058241;9.035198,40.087822

[quaelnix]

This should do what you want: https://paste.rs/DmQ4n, but it will still fail on the last example, because you modified the tags on this gate: https://www.openstreetmap.org/node/10936600030/history, two days ago, just after the rd5 data has been updated on the test server for the last time.

[LupinSun]

This should do what you want: https://paste.rs/DmQ4n, but it will still fail on the last example, because you modified the tags on this gate: https://www.openstreetmap.org/node/10936600030/history, two days ago, just after the rd5 data has been updated on the test server for the last time.

Ok I understand, I never considered the data date, my fault, I thought that data after one day are updated. In any case, it is not computed well, I changed the zone in order to have an older date, but the compute is wrong, in fact I don't understand it at all, _NoGate works correctly, while _unknowngate behaves in a strange way. Look here, I searched for two other nearby gates in another area with older data date http://148.251.191.149/brouter-web/#map=15/39.7438/8.6963/standard&lonlats=8.690793,39.745474;8.689628,39.747153

[quaelnix]

Guess I had a bad day.

... switch ( and Unknown_Gate motorcycle=yes ) 1000000 0

->

... switch ( and not Unknown_Gate not motorcycle=yes ) 1000000 0

problem gone: https://paste.rs/PsEaJ

---

But I think you should consider a different approach (see: https://paste.rs/xazBM): to avoid any further confusion. ;-)

[LupinSun]

Guess I had a bad day.

I'm sorry

... switch ( and Unknown_Gate motorcycle=yes ) 1000000 0

->

... switch ( and not Unknown_Gate not motorcycle=yes ) 1000000 0

problem gone: https://paste.rs/PsEaJ

:blush:

But I think you should consider a different approach (see: https://paste.rs/xazBM): to avoid any further confusion. ;-)

That would have been the next step, but I wasn't going to ask you for help. so thank you, you went further, you read my mind :relaxed: if you come on holiday in Sardinia, I will be happy to meet you and offer you beer and pizza :beers:

[LupinSun]

@quaelnix @zossebart @0709wiwiwi @poutnikl I need your help again, I don't know if this can be fixed though. If I add the rock or rocks or rocky value to the key "surface" brouter by error see attachment, yet in osm it exists, even if it is little used, while other values ​​such as unpaved or dirt are ok

[poutnikl]

From all registered OSM surface=* tagvalues, only those listed in lookups.dat file at brouter.de are allowed - see below.

Numbers are AFAIK occurances in Germany tiles. With several tagvalues, all are encoded as the first one.

surface;0002497676 asphalt
surface;0001568957 paved
surface;0001562253 unpaved
surface;0000727427 gravel
surface;0000560191 ground
surface;0000350378 dirt
surface;0000237226 grass
surface;0000212587 concrete concrete:plates concrete:lanes
surface;0000188743 paving_stones paving_stones:30 paving_stones:20
surface;0000113800 cobblestone cobblestone:flattened
surface;0000093164 compacted
surface;0000091171 sand dirt/sand
surface;0000023293 wood
surface;0000019915 pebblestone
surface;0000012866 fine_gravel
surface;0000010681 earth
surface;0000007331 sett
surface;0000005778 mud
surface;0000004549 grass_paver
surface;0000004398 clay
surface;0000003760 metal

[quaelnix]

@LupinSun, surface=rock will be supported once #458 is merged:

surface;0000000001 rock rocks rocky

[LupinSun]

@LupinSun, surface=rock will be supported once #458 is merged:

surface;0000000001 rock rocks rocky

Very well, thank you