Re: [mkgmap-dev] splitter with --polygon-desc-file crashes
Hi.
Just after splitter reports that it stats with the second country (estonia in
lower case is the country name within the polygon file).
--resolution=15 combined with --max-nodes=75000 did not change...
Some of the output:
Rounded map coverage is (55.634765625,19.7314453125) to
(60.029296875,28.2568359375)
Splitting nodes into areas containing a maximum of 75 000 nodes each...
splitting distinct part of latvia
Highest node count in a single grid element is 83 999
Highest node count in a single grid element within the bounding polygon is
77 110
...
continues.
Then splitter reports "splitting distinct part of estonia" thereafter:
java.lang.NullPointerException
at
uk.me.parabola.splitter.solver.DensityMap.getNodeCount(DensityMap.java:156)
at
uk.me.parabola.splitter.solver.EnhancedDensityMap.prepare(EnhancedDensityMap.java:
83)
at
uk.me.parabola.splitter.solver.EnhancedDensityMap.(EnhancedDensityMap.java:
43)
at
uk.me.parabola.splitter.solver.SplittableDensityArea.prepare(SplittableDensityArea.java:
339)
at
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:
177)
at
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:
237)
at
uk.me.parabola.splitter.solver.AreasCalculator.calcAreas(AreasCalculator.java:
228)
at uk.me.parabola.splitter.Main.split(Main.java:227)
at uk.me.parabola.splitter.Main.start(Main.java:121)
at uk.me.parabola.splitter.Main.main(Main.java:81)
I can add the full output if it may be of any use.
Regards
Karl
On onsdag 16 februari 2022 18:35:51 CET Gerd Petermann wrote:
> Hi Karl,
>
> I've not tried it yet. What is the error message from splitter?
> When experimenting with small files it sometimes makes sense to increase
> the resolution (14 or 15) and lower the --max-nodes values to get closer to
> a large scale result (like > 100 tiles or so)
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von 7770
> <7...@foskan.eu> Gesendet: Mittwoch, 16. Februar 2022 17:52
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] splitter with --polygon-desc-file crashes
>
> Hi.
> I have asked long ago about this particular problem i have and it was long
> time ago i last tried, but now i did again. It relates to splitter and usage
> of --polygon-desc-file=
>
> This is how i have tried:
> 1. Download data for Estonia and Latvia.
> https://download.geofabrik.de/europe/estonia-latest.osm.pbf
> https://download.geofabrik.de/europe/latvia-latest.osm.pbf
>
> 2. convert to o5m and combine
> osmconvert estonia-latest.osm.pbf -o=estonia-latest.osm.o5m;
> osmconvert latvia-latest.osm.pbf -o=latvia-latest.osm.o5m;
> osmconvert estonia-latest.osm.o5m latvia-latest.osm.o5m -o=ee_lv.o5m;
>
> 3. Prepare an osm-polygon file with one area for Estonia and one for Latvia.
> (file attached)
>
> 4. Run splitter:
> java -Xmx2000m -jar ${SPLITTER} \
> --polygon-desc-file=./polygon_ee_lv.osm \
> --output-dir=ee_lv/splitted/ \
> --max-nodes=75 \
> --no-trim \
> ee_lv.o5m
>
>
> While running this is seems like the Latvia part is fine, but the Estonia
> crashes.
>
>
> The error message doesn't say much (that i understand).
> But maybe it makes some sense to you?
> I imagine something is wrong with the polygon file, but i dont know what.
>
> The polygon files is partially made in JOSM and partially manaully to re-use
> the same segments/edges which belong to both countries. (I could see that
> Gerd was using this concept in some example file for Germany and the alps,
> but i could not add two ways over one edge in JOSM, so i made manual
> chanegs in the file).
> I tried also making two separate boxes, one for each country, but that was
> just as bad (not reusing edges).
>
> Anything that could be suggested that i change or try?
>
> PS. i am trying this on small scale for two smaller countries, later i will
> apply it because i need to split europe in parts of max 4GB.
>
> Regards
> Karl
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter with --polygon-desc-file crashes
Hi Karl,
I've not tried it yet. What is the error message from splitter?
When experimenting with small files it sometimes makes sense to increase
the resolution (14 or 15) and lower the --max-nodes values to get closer to a
large scale
result (like > 100 tiles or so)
Gerd
Von: mkgmap-dev im Auftrag von 7770
<7...@foskan.eu>
Gesendet: Mittwoch, 16. Februar 2022 17:52
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter with --polygon-desc-file crashes
Hi.
I have asked long ago about this particular problem i have and it was long
time ago i last tried, but now i did again. It relates to splitter and usage
of --polygon-desc-file=
This is how i have tried:
1. Download data for Estonia and Latvia.
https://download.geofabrik.de/europe/estonia-latest.osm.pbf
https://download.geofabrik.de/europe/latvia-latest.osm.pbf
2. convert to o5m and combine
osmconvert estonia-latest.osm.pbf -o=estonia-latest.osm.o5m;
osmconvert latvia-latest.osm.pbf -o=latvia-latest.osm.o5m;
osmconvert estonia-latest.osm.o5m latvia-latest.osm.o5m -o=ee_lv.o5m;
3. Prepare an osm-polygon file with one area for Estonia and one for Latvia.
(file attached)
4. Run splitter:
java -Xmx2000m -jar ${SPLITTER} \
--polygon-desc-file=./polygon_ee_lv.osm \
--output-dir=ee_lv/splitted/ \
--max-nodes=75 \
--no-trim \
ee_lv.o5m
While running this is seems like the Latvia part is fine, but the Estonia
crashes.
The error message doesn't say much (that i understand).
But maybe it makes some sense to you?
I imagine something is wrong with the polygon file, but i dont know what.
The polygon files is partially made in JOSM and partially manaully to re-use
the same segments/edges which belong to both countries. (I could see that Gerd
was using this concept in some example file for Germany and the alps, but i
could not add two ways over one edge in JOSM, so i made manual chanegs in the
file).
I tried also making two separate boxes, one for each country, but that was
just as bad (not reusing edges).
Anything that could be suggested that i change or try?
PS. i am trying this on small scale for two smaller countries, later i will
apply it because i need to split europe in parts of max 4GB.
Regards
Karl
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to-ways
operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the
way, so it will have values like:
mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg:
mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg:
highway=service & access!=* & mkgmap:poi-barrier=* &
mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*"
{set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
On Tue, 2022-02-15 at 16:41 +, Ticker Berkin wrote:
> Hi Gerd
>
> highway=street_lamp was just an example of a POI that can get linked
> to
> a WAY that can be ignored. There are others that are valid OSM
> tagging
> that are irrelevant to the highway behaviour.
>
> Actually, regardless of --link-pois-to-ways, there is a problem in
> the
> scenario where there is typical road system linked to a small road
> system by just a road with mkgmap:throughroute=no and a footway.
> BaseCamp and the eTrex 30x really will route over the footway to get
> into the small road system. MapSource and, I think, the eTrex HCx
> will
> use the road.
>
> I realise that this set-up seems unlikely, but can happen if there is
> an inconsistency in the tagging of roads in the small system that
> results in one not having mkgmap:throughroute=no that is joined to
> the
> footway. My example happened in a business park.
>
> My style makes this problem more likely to happen, while also trying
> to
> fix it, by not setting mkgmap:throughroute=no unless there seems to
> be
> a good reason for it. Good reasons are when there is a barrier on a
> service road. This is the test I want to improve.
>
> Ticker
>
> On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > if you find highway=street_lamp nodes on highway=* ways those are
> > errors and should be fixed in OSM.
> > Street lamps are normally mapped along the road, not on the road.
> >
> > Maybe you meant highway=traffic_signals?
> >
> > Besides that Basecamp should never route a car over a footway. That
> > sounds like an error in the map data produced by mkgmap
> > or maybe you used wrong routing settings. Please let me know how to
> > reproduce.
> >
> > No idea if your proposed change would improve routing, but feel
> > free
> > to experiment with that.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Dienstag, 15. Februar 2022 13:37
> > An: mkgmap development
> > Betreff: [mkgmap-dev] option link-pois-to-ways information
> >
> > Hi all
> >
> > To improve routing, I'd like to get information about the POIS that
> > are
> > being linked to a WAY that can be used as part of the style/lines
> > processing.
> >
> > The problem I'm trying to solve is to restrict car routing through
> > some
> > types of very low level roads (eg service) when there is a barrier.
> > Setting mkgmap:throughroute=no on these works nicely with MapSource
> > and
> > older devices but BaseCamp and newer devices will happily route
> > over
> > a
> > footpath to avoid a throughroute=no section.
> >
> > At the moment, with --link-pois-to-ways, if the POI has a barrier
> > or
> > highway tag, mkgmap:way-has-pois is set true. This can be tested by
> > lines, inc/access etc, but there is no way to find out if it is a
> > significant barrier or something like highway=street_lamp.
> >
> > points processing can set mkgmap: access & road_speed/class
> > variables
> > that are handled by inbuild code after lines processing to imposes
> > more
> > restrictions on the way and/or reduces speed/class; this is no use
> > for
> > what I want to do.
> >
> > Possibilities are:
> > 1/ have options to say which POI tag/value combinations cause
> > link-pois-to-ways
> > 2/ set new variables on the way, eg
> > mkgmap:barrier_tags/highway_tags,
> > which are a list of distinct POI highway/barrier tag values.
> >
> > Ticker
> >
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java (revision 4896)
+++ src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java (working copy)
@@ -100,11 +100,11 @@
// if this Coord is also a POI, replace it with an
// equivalent CoordPOI that
[mkgmap-dev] splitter with --polygon-desc-file crashes
Hi.
I have asked long ago about this particular problem i have and it was long
time ago i last tried, but now i did again. It relates to splitter and usage
of --polygon-desc-file=
This is how i have tried:
1. Download data for Estonia and Latvia.
https://download.geofabrik.de/europe/estonia-latest.osm.pbf
https://download.geofabrik.de/europe/latvia-latest.osm.pbf
2. convert to o5m and combine
osmconvert estonia-latest.osm.pbf -o=estonia-latest.osm.o5m;
osmconvert latvia-latest.osm.pbf -o=latvia-latest.osm.o5m;
osmconvert estonia-latest.osm.o5m latvia-latest.osm.o5m -o=ee_lv.o5m;
3. Prepare an osm-polygon file with one area for Estonia and one for Latvia.
(file attached)
4. Run splitter:
java -Xmx2000m -jar ${SPLITTER} \
--polygon-desc-file=./polygon_ee_lv.osm \
--output-dir=ee_lv/splitted/ \
--max-nodes=75 \
--no-trim \
ee_lv.o5m
While running this is seems like the Latvia part is fine, but the Estonia
crashes.
The error message doesn't say much (that i understand).
But maybe it makes some sense to you?
I imagine something is wrong with the polygon file, but i dont know what.
The polygon files is partially made in JOSM and partially manaully to re-use
the same segments/edges which belong to both countries. (I could see that Gerd
was using this concept in some example file for Germany and the alps, but i
could not add two ways over one edge in JOSM, so i made manual chanegs in the
file).
I tried also making two separate boxes, one for each country, but that was
just as bad (not reusing edges).
Anything that could be suggested that i change or try?
PS. i am trying this on small scale for two smaller countries, later i will
apply it because i need to split europe in parts of max 4GB.
Regards
Karl
polygon_ee_lv.osm
Description: application/osm
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] some findings about NT format
Hi all, my findings so far which are not used / needed in GPXSee. Maybe it helps someone else: - method linkLabel() could extract further road labels, bit 0x80 flags the last of up to 4 labels. - method linkLabel() extracts a flag, the bit 0x08 in this flag seems to signal a tunnel. No idea yet what the other bits mean. - the flags field in struct LinkInfo is used like this (netfile.cpp) bool firstIsShape = (linkInfo.flags >> 10) & 1; bool singleTopology = (linkInfo.flags >> 9) & 1; bool hasLevels = (linkInfo.flags >> 11) & 1; My guesses about the meaning of the lower bits: // int road_speed = linkInfo.flags & 7; // bool oneway = (linkInfo.flags >> 3) & 1; // int road_class = (linkInfo.flags >> 4) & 7; - The NET header can have two more sections, e.g. I see 0684 | f6 cb 13 00 | NET5 ???, offset 13cbf6 0688 | 96 0a 01 00 | NET5 ???, length 68246 068c | 23 00 | ??? 068e | 8c d6 14 00 | NET6 ???, offset 14d68c 0692 | 28 05 00 00 | NET6 ???, length 1320 0696 | 03 00 | NET6 ??? record size 3 0698 | 02 00 00 00 | ??? NET6 contains a list of offsets into NET4, they are in sorted order and each offset points to the byte following the flag byte that is read in linkLabel() I see 440 recrods here, and 441 NOD6 records in the corresponding NOD file, so they are obviously related (field blockIndexId). I've not yet found where the address info like city name, zip name, and house numbers are stored. Maybe that's in NET5. I think in the old non-NT format there is no need to know NOD data to be able to read NET, so I woulld expect that this is also possible with NT maps. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Eric,
the dead-end-check is performed if the corresponding option --report-dead-end
is given
It is done after(!) the style rules were processed and the road network is
known.
A dead-end is a place on a oneway road where you can either no go back from or
not come to
with a vehicle.
No idea how this is related to your service roads problem.
Gerd
Von: mkgmap-dev im Auftrag von
ankeric@gmail.com
Gesendet: Mittwoch, 16. Februar 2022 11:57
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd,
Question ("On Topic" or "Off Topic"):
Has mkgmap (Internal tags) an option to "Set mkgmap:dead-end = true"?
I do read:
mkgmap:dead-end-check Set to false to disable the dead-end-check for a
specific way report-dead-ends
But: what is "dead-end-check"?
I would like to have this option:
highway=service | highway=track & mkgmap:dead-end = true {set access=private}
(Do not ignore a dead-end mountain valley, f.i.)
(OsmAnd can handle "access=private". Garmin cannot, but I can manually ignore)
I do use:
bicycle=destination { set highway=service; set bicycle=yes; set
mkgmap:throughroute=no }
But I don't use:
"mkgmap:throughroute=no" for navigation. So: useless???
Because I don't know how to...
BTW, FWIW:
In the Netherlands "they" have set {access=private} on ALL "highway=service"
"service=driveway" (oké, only in my region).
Making Address navigation by Garmin impossible.
AnkEric
-Original Message-
From: mkgmap-dev On Behalf Of Gerd
Petermann
Sent: woensdag 16 februari 2022 10:25
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker,
reg. routing problems in Basecamp: Maybe you hit the problem described for
--max-routing-island-len?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 15. Februar 2022 17:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
highway=street_lamp was just an example of a POI that can get linked to a WAY
that can be ignored. There are others that are valid OSM tagging that are
irrelevant to the highway behaviour.
Actually, regardless of --link-pois-to-ways, there is a problem in the scenario
where there is typical road system linked to a small road system by just a road
with mkgmap:throughroute=no and a footway.
BaseCamp and the eTrex 30x really will route over the footway to get into the
small road system. MapSource and, I think, the eTrex HCx will use the road.
I realise that this set-up seems unlikely, but can happen if there is an
inconsistency in the tagging of roads in the small system that results in one
not having mkgmap:throughroute=no that is joined to the footway. My example
happened in a business park.
My style makes this problem more likely to happen, while also trying to fix it,
by not setting mkgmap:throughroute=no unless there seems to be a good reason
for it. Good reasons are when there is a barrier on a service road. This is the
test I want to improve.
Ticker
On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if you find highway=street_lamp nodes on highway=* ways those are
> errors and should be fixed in OSM.
> Street lamps are normally mapped along the road, not on the road.
>
> Maybe you meant highway=traffic_signals?
>
> Besides that Basecamp should never route a car over a footway. That
> sounds like an error in the map data produced by mkgmap or maybe you
> used wrong routing settings. Please let me know how to reproduce.
>
> No idea if your proposed change would improve routing, but feel free
> to experiment with that.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 15. Februar 2022 13:37
> An: mkgmap development
> Betreff: [mkgmap-dev] option link-pois-to-ways information
>
> Hi all
>
> To improve routing, I'd like to get information about the POIS that
> are being linked to a WAY that can be used as part of the style/lines
> processing.
>
> The problem I'm trying to solve is to restrict car routing through
> some types of very low level roads (eg service) when there is a
> barrier.
> Setting mkgmap:throughroute=no on these works nicely with MapSource
> and older devices but BaseCamp and newer devices will happily route
> over a footpath to avoid a throughroute=no section.
>
> At the moment, with --link-pois-to-ways, if the POI has a barrier or
> highway tag, mkgmap:way-has-pois is set true. This can be tested by
> lines, inc/access etc, but there is no way to find out if it is a
> significant barrier or something like highway=street_lamp.
>
> points processing can set mkgmap: access & road_speed/class variables
> that are handled by inbuild code after lines processing to imposes
> more restrictions on the way and/or reduces speed/class; this is no
> use
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd I've been testing with all the routing-island options set to -1 and the small road network has 2 connections to the wider network, so I don't think it is related. If the destination in the small network is only accessible by (joined, I think, but not tested) roads with throughroute=no, then it uses them rather than the footpath. If there is no footpath, so the only access to the destination (on a throughRoute) is via a throughRoute=no, it resorts to straigh-line routine All above is Basecamp. Mapsource overrides throughRoute=no instead of car=no Ticker On Wed, 2022-02-16 at 09:25 +, Gerd Petermann wrote: > Hi Ticker, > > reg. routing problems in Basecamp: Maybe you hit the problem > described for --max-routing-island-len? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 15. Februar 2022 17:41 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] option link-pois-to-ways information > > Hi Gerd > > highway=street_lamp was just an example of a POI that can get linked > to > a WAY that can be ignored. There are others that are valid OSM > tagging > that are irrelevant to the highway behaviour. > > Actually, regardless of --link-pois-to-ways, there is a problem in > the > scenario where there is typical road system linked to a small road > system by just a road with mkgmap:throughroute=no and a footway. > BaseCamp and the eTrex 30x really will route over the footway to get > into the small road system. MapSource and, I think, the eTrex HCx > will > use the road. > > I realise that this set-up seems unlikely, but can happen if there is > an inconsistency in the tagging of roads in the small system that > results in one not having mkgmap:throughroute=no that is joined to > the > footway. My example happened in a business park. > > My style makes this problem more likely to happen, while also trying > to > fix it, by not setting mkgmap:throughroute=no unless there seems to > be > a good reason for it. Good reasons are when there is a barrier on a > service road. This is the test I want to improve. > > Ticker > > On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote: > > Hi Ticker, > > > > if you find highway=street_lamp nodes on highway=* ways those are > > errors and should be fixed in OSM. > > Street lamps are normally mapped along the road, not on the road. > > > > Maybe you meant highway=traffic_signals? > > > > Besides that Basecamp should never route a car over a footway. That > > sounds like an error in the map data produced by mkgmap > > or maybe you used wrong routing settings. Please let me know how to > > reproduce. > > > > No idea if your proposed change would improve routing, but feel > > free > > to experiment with that. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 15. Februar 2022 13:37 > > An: mkgmap development > > Betreff: [mkgmap-dev] option link-pois-to-ways information > > > > Hi all > > > > To improve routing, I'd like to get information about the POIS that > > are > > being linked to a WAY that can be used as part of the style/lines > > processing. > > > > The problem I'm trying to solve is to restrict car routing through > > some > > types of very low level roads (eg service) when there is a barrier. > > Setting mkgmap:throughroute=no on these works nicely with MapSource > > and > > older devices but BaseCamp and newer devices will happily route > > over > > a > > footpath to avoid a throughroute=no section. > > > > At the moment, with --link-pois-to-ways, if the POI has a barrier > > or > > highway tag, mkgmap:way-has-pois is set true. This can be tested by > > lines, inc/access etc, but there is no way to find out if it is a > > significant barrier or something like highway=street_lamp. > > > > points processing can set mkgmap: access & road_speed/class > > variables > > that are handled by inbuild code after lines processing to imposes > > more > > restrictions on the way and/or reduces speed/class; this is no use > > for > > what I want to do. > > > > Possibilities are: > > 1/ have options to say which POI tag/value combinations cause > > link-pois-to-ways > > 2/ set new variables on the way, eg > > mkgmap:barrier_tags/highway_tags, > > which are a list of distinct POI highway/barrier tag values. > > > > Ticker > > > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd,
Question ("On Topic" or "Off Topic"):
Has mkgmap (Internal tags) an option to "Set mkgmap:dead-end = true"?
I do read:
mkgmap:dead-end-check Set to false to disable the dead-end-check for a
specific way report-dead-ends
But: what is "dead-end-check"?
I would like to have this option:
highway=service | highway=track & mkgmap:dead-end = true {set access=private}
(Do not ignore a dead-end mountain valley, f.i.)
(OsmAnd can handle "access=private". Garmin cannot, but I can manually ignore)
I do use:
bicycle=destination { set highway=service; set bicycle=yes; set
mkgmap:throughroute=no }
But I don't use:
"mkgmap:throughroute=no" for navigation. So: useless???
Because I don't know how to...
BTW, FWIW:
In the Netherlands "they" have set {access=private} on ALL "highway=service"
"service=driveway" (oké, only in my region).
Making Address navigation by Garmin impossible.
AnkEric
-Original Message-
From: mkgmap-dev On Behalf Of Gerd
Petermann
Sent: woensdag 16 februari 2022 10:25
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker,
reg. routing problems in Basecamp: Maybe you hit the problem described for
--max-routing-island-len?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 15. Februar 2022 17:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
highway=street_lamp was just an example of a POI that can get linked to a WAY
that can be ignored. There are others that are valid OSM tagging that are
irrelevant to the highway behaviour.
Actually, regardless of --link-pois-to-ways, there is a problem in the scenario
where there is typical road system linked to a small road system by just a road
with mkgmap:throughroute=no and a footway.
BaseCamp and the eTrex 30x really will route over the footway to get into the
small road system. MapSource and, I think, the eTrex HCx will use the road.
I realise that this set-up seems unlikely, but can happen if there is an
inconsistency in the tagging of roads in the small system that results in one
not having mkgmap:throughroute=no that is joined to the footway. My example
happened in a business park.
My style makes this problem more likely to happen, while also trying to fix it,
by not setting mkgmap:throughroute=no unless there seems to be a good reason
for it. Good reasons are when there is a barrier on a service road. This is the
test I want to improve.
Ticker
On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if you find highway=street_lamp nodes on highway=* ways those are
> errors and should be fixed in OSM.
> Street lamps are normally mapped along the road, not on the road.
>
> Maybe you meant highway=traffic_signals?
>
> Besides that Basecamp should never route a car over a footway. That
> sounds like an error in the map data produced by mkgmap or maybe you
> used wrong routing settings. Please let me know how to reproduce.
>
> No idea if your proposed change would improve routing, but feel free
> to experiment with that.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 15. Februar 2022 13:37
> An: mkgmap development
> Betreff: [mkgmap-dev] option link-pois-to-ways information
>
> Hi all
>
> To improve routing, I'd like to get information about the POIS that
> are being linked to a WAY that can be used as part of the style/lines
> processing.
>
> The problem I'm trying to solve is to restrict car routing through
> some types of very low level roads (eg service) when there is a
> barrier.
> Setting mkgmap:throughroute=no on these works nicely with MapSource
> and older devices but BaseCamp and newer devices will happily route
> over a footpath to avoid a throughroute=no section.
>
> At the moment, with --link-pois-to-ways, if the POI has a barrier or
> highway tag, mkgmap:way-has-pois is set true. This can be tested by
> lines, inc/access etc, but there is no way to find out if it is a
> significant barrier or something like highway=street_lamp.
>
> points processing can set mkgmap: access & road_speed/class variables
> that are handled by inbuild code after lines processing to imposes
> more restrictions on the way and/or reduces speed/class; this is no
> use for what I want to do.
>
> Possibilities are:
> 1/ have options to say which POI tag/value combinations cause
>link-pois-to-ways
> 2/ set new variables on the way, eg mkgmap:barrier_tags/highway_tags,
>which are a list of distinct POI highway/barrier tag values.
>
> Ticker
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
>
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker, reg. routing problems in Basecamp: Maybe you hit the problem described for --max-routing-island-len? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 15. Februar 2022 17:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information Hi Gerd highway=street_lamp was just an example of a POI that can get linked to a WAY that can be ignored. There are others that are valid OSM tagging that are irrelevant to the highway behaviour. Actually, regardless of --link-pois-to-ways, there is a problem in the scenario where there is typical road system linked to a small road system by just a road with mkgmap:throughroute=no and a footway. BaseCamp and the eTrex 30x really will route over the footway to get into the small road system. MapSource and, I think, the eTrex HCx will use the road. I realise that this set-up seems unlikely, but can happen if there is an inconsistency in the tagging of roads in the small system that results in one not having mkgmap:throughroute=no that is joined to the footway. My example happened in a business park. My style makes this problem more likely to happen, while also trying to fix it, by not setting mkgmap:throughroute=no unless there seems to be a good reason for it. Good reasons are when there is a barrier on a service road. This is the test I want to improve. Ticker On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote: > Hi Ticker, > > if you find highway=street_lamp nodes on highway=* ways those are > errors and should be fixed in OSM. > Street lamps are normally mapped along the road, not on the road. > > Maybe you meant highway=traffic_signals? > > Besides that Basecamp should never route a car over a footway. That > sounds like an error in the map data produced by mkgmap > or maybe you used wrong routing settings. Please let me know how to > reproduce. > > No idea if your proposed change would improve routing, but feel free > to experiment with that. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 15. Februar 2022 13:37 > An: mkgmap development > Betreff: [mkgmap-dev] option link-pois-to-ways information > > Hi all > > To improve routing, I'd like to get information about the POIS that > are > being linked to a WAY that can be used as part of the style/lines > processing. > > The problem I'm trying to solve is to restrict car routing through > some > types of very low level roads (eg service) when there is a barrier. > Setting mkgmap:throughroute=no on these works nicely with MapSource > and > older devices but BaseCamp and newer devices will happily route over > a > footpath to avoid a throughroute=no section. > > At the moment, with --link-pois-to-ways, if the POI has a barrier or > highway tag, mkgmap:way-has-pois is set true. This can be tested by > lines, inc/access etc, but there is no way to find out if it is a > significant barrier or something like highway=street_lamp. > > points processing can set mkgmap: access & road_speed/class variables > that are handled by inbuild code after lines processing to imposes > more > restrictions on the way and/or reduces speed/class; this is no use > for > what I want to do. > > Possibilities are: > 1/ have options to say which POI tag/value combinations cause >link-pois-to-ways > 2/ set new variables on the way, eg mkgmap:barrier_tags/highway_tags, >which are a list of distinct POI highway/barrier tag values. > > Ticker > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
