Re: [mkgmap-dev] Bad tile around East London / Greenwich

[lig fietser]

Hi,
I've tried it too with my OFM full style and mkgmap v 4802 but it doesn't show 
any issues at all.
Maybe some parameters are different? I don't use:
pois-to-areas-placement
poi-excl-index
nearby-poi-rules


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Bad tile around East London / Greenwich

[lig fietser]

Hi Gerd and Jan,
I have found the difference  that caused this issue for you and not for me:
I have used the parameter ignore-turn-restrictions . Now I can remember I have 
seen this issue too in a tile in the UK as well, and by adding this it was 
solved. Does this make sense Gerd?

Mfrgr, Minko




Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 7 augustus 2021 08:51
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] Bad tile around East London / Greenwich

Hi Minko,

I just tried with the latest version of the OFM style and I can still reproduce 
the problem with r4802.
I adapted he paths in Jans  args and commented only the DEM options.
I can also reproduce it with these few options:
java -jar mkgmap.jar --route --link-pois-to-ways 
--style-file="d:\git_repos\minko\styles\Openfietsmap full" 
e:\jan\10700105.osm.pbf

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 7. August 2021 17:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Bad tile around East London / Greenwich

Hi,
I've tried it too with my OFM full style and mkgmap v 4802 but it doesn't show 
any issues at all.
Maybe some parameters are different? I don't use:
pois-to-areas-placement
poi-excl-index
nearby-poi-rules


___
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] Bad tile around East London / Greenwich

[lig fietser]

Thanks for the explanation and the fix Gerd!



Hi Minko,

well, yes, the problem is caused by an extreme density of (Garmin) route 
restrictions. Those are created for OSM turn restrictions and also for barriers 
when --link-pois-to-ways is used. Maybe this area contains many 
type=restriction relations with via ways, those require more bytes compared to 
simple turn restrictions with one via node.
I think the fix in r4805 is the better alternative compared to using 
--ignore-turn-restrictions.

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] --version

[lig fietser]

Hi,
If I run the command java -jar mkgmap.jar --version
it will print a double version in the output, like this

Map created with Mkgmap version 4805
4805

I've used a quite outdated mkgmap version (mkgmap-r4285) whose only output was: 
4285
How can I get rid of the double 4805 4805?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] --version

[lig fietser]

Hi Gerd,
I work with windows (Dos commands) ;-)
Yes, I've found a workaround that only print the last line: more +1 version.txt
That works for me, thanks!




Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 14 augustus 2021 04:38
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] --version

Hi Minko,

I expected this question ;)
The change was introduced with r4656: 
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4656

I don't know for sure why Mike added this line. I think I asked that before but 
I can't find my post. Maybe I never sent it...

Is it difficult to extract the last line? I think on Linux the tool tail should 
help with that.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 14. August 2021 13:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] --version

Hi,
If I run the command java -jar mkgmap.jar --version
it will print a double version in the output, like this

Map created with Mkgmap version 4805
4805

I've used a quite outdated mkgmap version (mkgmap-r4285) whose only output was: 
4285
How can I get rid of the double 4805 4805?



___
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] elevation in bridges and tunnels

[lig fietser]

Hi guys,
I came across this video on youtube, where ridewithgps.com improved their 
elevation profiles by ignoring the underlying altititude data of tunnel and 
bridges:
 https://youtu.be/wd-wT3EeayI
I found out that other route planners like brouter, cycle.travel and Osmand 
also ignores the surface altitude that lies above tunnels and underneath 
bridges, but mkgmap/Garmin does not. This leads to a much higher elevation gain 
or loss in the route profile than the actual ride. Is it possible for mkgmap to 
correct this issue, or is it hard coded in the Garmin Basecamp software?




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] elevation in bridges and tunnels

[lig fietser]

I've put an example on this forum (in Dutch). The brouter route 
(https://tinyurl.com/3nt27szy) shows a profile that is more accurate than the 
route in Basecamp.

https://forum.wereldfietser.nl/viewtopic.php?f=3&t=30684&p=412494#p412494

Van: mkgmap-dev  namens lig fietser 

Verzonden: woensdag 19 januari 2022 23:55
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] elevation in bridges and tunnels


Hi guys,
I came across this video on youtube, where ridewithgps.com improved their 
elevation profiles by ignoring the underlying altititude data of tunnel and 
bridges:
 https://youtu.be/wd-wT3EeayI
I found out that other route planners like brouter, cycle.travel and Osmand 
also ignores the surface altitude that lies above tunnels and underneath 
bridges, but mkgmap/Garmin does not. This leads to a much higher elevation gain 
or loss in the route profile than the actual ride. Is it possible for mkgmap to 
correct this issue, or is it hard coded in the Garmin Basecamp software?




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] elevation in bridges and tunnels

[lig fietser]

Thanks Gerd,
It's a pity that this cannot be corrected. I thought the route could look where 
a tunnel/bridge section is (based on OSM tags) and just ignore all elevation 
data and starts reading it where there is no tunnel or bridge tag?


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 20 januari 2022 00:34
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] elevation in bridges and tunnels

Hi all,

I also don't like the wrong profile for bridges and tunnels, but there is 
nothing we can do about this so far.
The other routers know that the have to treat bridges and tunnel special, but 
Garmin software doesn't have this information.
We also cannot manipulate the elevation data because there may be another 
highway under the bridge or above the tunnel.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Donnerstag, 20. Januar 2022 09:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] elevation in bridges and tunnels

I've put an example on this forum (in Dutch). The brouter route 
(https://tinyurl.com/3nt27szy) shows a profile that is more accurate than the 
route in Basecamp.

https://forum.wereldfietser.nl/viewtopic.php?f=3&t=30684&p=412494#p412494
____
Van: mkgmap-dev  namens lig fietser 

Verzonden: woensdag 19 januari 2022 23:55
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] elevation in bridges and tunnels


Hi guys,
I came across this video on youtube, where ridewithgps.com improved their 
elevation profiles by ignoring the underlying altititude data of tunnel and 
bridges:
 https://youtu.be/wd-wT3EeayI
I found out that other route planners like brouter, cycle.travel and Osmand 
also ignores the surface altitude that lies above tunnels and underneath 
bridges, but mkgmap/Garmin does not. This leads to a much higher elevation gain 
or loss in the route profile than the actual ride. Is it possible for mkgmap to 
correct this issue, or is it hard coded in the Garmin Basecamp software?




___
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] elevation in bridges and tunnels

[lig fietser]

Thanks Gerd, it is what it is. Then I'll stick with brouter or rwgps to make 
more accurate elevation profiles.

Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 20 januari 2022 00:44
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] elevation in bridges and tunnels

Hi Minko,

there is no special flag for tunnel/bridge in the IMG format, at least we don't 
know any. So, Garmin software cannot detect the special case.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Donnerstag, 20. Januar 2022 09:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] elevation in bridges and tunnels

Thanks Gerd,
It's a pity that this cannot be corrected. I thought the route could look where 
a tunnel/bridge section is (based on OSM tags) and just ignore all elevation 
data and starts reading it where there is no tunnel or bridge tag?


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 20 januari 2022 00:34
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] elevation in bridges and tunnels

Hi all,

I also don't like the wrong profile for bridges and tunnels, but there is 
nothing we can do about this so far.
The other routers know that the have to treat bridges and tunnel special, but 
Garmin software doesn't have this information.
We also cannot manipulate the elevation data because there may be another 
highway under the bridge or above the tunnel.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Donnerstag, 20. Januar 2022 09:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] elevation in bridges and tunnels

I've put an example on this forum (in Dutch). The brouter route 
(https://tinyurl.com/3nt27szy) shows a profile that is more accurate than the 
route in Basecamp.

https://forum.wereldfietser.nl/viewtopic.php?f=3&t=30684&p=412494#p412494
____________
Van: mkgmap-dev  namens lig fietser 

Verzonden: woensdag 19 januari 2022 23:55
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] elevation in bridges and tunnels


Hi guys,
I came across this video on youtube, where ridewithgps.com improved their 
elevation profiles by ignoring the underlying altititude data of tunnel and 
bridges:
 https://youtu.be/wd-wT3EeayI
I found out that other route planners like brouter, cycle.travel and Osmand 
also ignores the surface altitude that lies above tunnels and underneath 
bridges, but mkgmap/Garmin does not. This leads to a much higher elevation gain 
or loss in the route profile than the actual ride. Is it possible for mkgmap to 
correct this issue, or is it hard coded in the Garmin Basecamp software?




___
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] mkgmap:area2poi placement

[lig fietser]

Hi,
I've noticed on my map that mkgmap places the poi of an area like the  
"Nationalpark Niedersächsisches Wattenmeer" 
(https://www.openstreetmap.org/relation/157811)  outside of the National Park, 
so not in the sea but on the mainland near Wittmund. I prefer to place those 
pois inside such odd shapes polygons. OSM carto puts the label just east of 
Borkum.  I'm not sure if there was a mkgmap option how to control this 
behaviour? I know it can be done by manipulating the OSM data and add a label, 
but I prefer to control this in mkgmap.






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap:area2poi placement

[lig fietser]

Ok, thanks.
Haven't tried the is_in function, I think the role=label works if there is a 
node in the OSM data but in this case there isn't any (and I won't want to add 
that because that could be seen as tagging for the renderer.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap:area2poi placement

[lig fietser]

Ok,
I've now managed to delete the poi with this line:
boundary=national park & mkgmap:area2poi=true & 
is_in(boundary,national_park,in_or_on)=false {delete boundary}

I also want to use it for all boundaries but this line is not working:
boundary=* & mkgmap:area2poi=true & is_in(boundary,*,in_or_on)=false {delete 
boundary}

How can I use the wildcard? According to the style manual this should be 
possible:

is_in(tag,value,method)
true if the element is in polygon(s) having the specified
tag=value according to the method, false otherwise.
value can be '*' which matches any polgon having tag. The
methods available depend on the Style section






I don't see a way to control the placement of the POI for a
multipolygon; it sets it to the centre point of the biggest area.

You could suppress the POI if it isn't within the area by using the
is_in() function, something like:

tag=value & mkgmap:area2poi=true & is_in(tag, value, in_or_on)=true
   [0x...]

Ticker

On Wed, 2022-04-06 at 07:46 +, lig fietser wrote:
> Hi,
> I've noticed on my map that mkgmap places the poi of an area like
> the  "Nationalpark Niedersächsisches Wattenmeer"
> (https://www.openstreetmap.org/relation/157811)  outside of the
> National Park, so not in the sea but on the mainland near Wittmund. I
> prefer to place those pois inside such odd shapes polygons. OSM carto
> puts the label just east of Borkum.  I'm not sure if there was a
> mkgmap option how to control this behaviour? I know it can be done by
> manipulating the OSM data and add a label, but I prefer to control
> this in mkgmap.
>
>
>
>
>
>
> ___
> 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] mkgmap:area2poi placement

[lig fietser]

Yes, I've tried to quote it but this does not exclude the poi, it still will be 
rendered somehow.
I've decided to use a workaround, I now make those "unwanted" pois only visible 
at the lower zoom levels (16-18).
This way it is not so obvious that they are way out of the national park 
boundaries and they will still be searchable in the index.







Van: mkgmap-dev  namens Ticker Berkin 

Verzonden: woensdag 6 april 2022 06:43
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] mkgmap:area2poi placement

Hi

The * needs to be quoted in the param list:
boundary=* &  ... & is_in(boundary, '*', ...

Ticker

On Wed, 2022-04-06 at 13:02 +, lig fietser wrote:
> I also want to use it for all boundaries but this line is not
> working:
> boundary=* & mkgmap:area2poi=true & is_in(boundary,*,in_or_on)=false
> {delete boundar

___
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] Question on routing difference

[lig fietser]

Hi Jan,
I also get the same route as test-route-b_yes-removed.jpg with the latest OFM 
Germany from 10=05-2022
(website is finally up to date since today).
It only takes the Altengabengäßchen when you move the via point closer to the 
junction Altengabengäßchen,
or when you select "avoid toll roads". I really don't know why, because there 
are no bike routes on these streets.
What I use is routing over short distance. avoid nothing (sometimes unpaved).  
Actually I don't use my Garmin at all,
I prefer Osmand with mobile phone (android) now 🙂


Cheers, Minko








Van: mkgmap-dev  namens jan meisters 

Verzonden: zaterdag 28 mei 2022 11:15
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] Question on routing difference

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ 
'(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

Thanks
Jan
___
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] Question on routing difference

[lig fietser]

Harri,
Thats why I use on my Openfietsmap not routable lines for highways with 
bicycle=no.
I misuse the avoidance of toll roads to force the routing to take cycle routes 
only.
In my scripts I retag all highways that are not part of a cycle route relation 
with toll=yes,
and all cycle routes with toll=no
I also "upgrade" cycleways and lower classified roads, but this comes indeed 
with a penalty of
slow or even impossible route calculations.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] multipolygon highway areas (like pedestrian)

[lig fietser]

Hi,

I have noticed mkgmap does not recognize multipolygon pedestrian areas that are 
tagged without area=yes as polygons.

Example: http://overpass-turbo.eu/s/l6k

Area=yes is I think not needed if it is a mulitpoygon, so I want to add this in 
my style (or maybe mkgmap should automatically recognize this) but how? I cant 
figure this out.


I have tried to add this rule in the relation style file:

type=multipolygon & highway=*
{ apply
  {
set area=yes
  }
}


But this does not work, pedestrian highways are still rendered as line and not 
as area. Also a rule like highway=* & (type=multipolygon|area=yes) in my 
polygon style does not work. Any ideas?


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] multipolygon highway areas (like pedestrian)

[lig fietser]

Thanks Gerd, works as expected now!


I have adapted the rule in my polygon style:

highway=* & (area=yes | mkgmap:mp_created=true) [0x0e resolution 23]


Something like this could also be done for the default style (polygon):


# squares and plazas
highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22]
# other highways that have area=yes set must be parking lots
highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22]




Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 7 januari 2017 04:32:52
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] multipolygon highway areas (like pedestrian)

See also this older thread:
http://gis.19327.n8.nabble.com/problem-with-highways-as-multipolygons-td5843801.html#a5843867

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 7. Januar 2017 13:18:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] multipolygon highway areas (like pedestrian)

I think you can check mkgmap:mp_created in the lines file.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 7. Januar 2017 12:07:56
An: mkgmap-dev
Betreff: [mkgmap-dev] multipolygon highway areas (like pedestrian)

Hi,

I have noticed mkgmap does not recognize multipolygon pedestrian areas that are 
tagged without area=yes as polygons.

Example: http://overpass-turbo.eu/s/l6k

Area=yes is I think not needed if it is a mulitpoygon, so I want to add this in 
my style (or maybe mkgmap should automatically recognize this) but how? I cant 
figure this out.


I have tried to add this rule in the relation style file:

type=multipolygon & highway=*
{ apply
  {
set area=yes
  }
}


But this does not work, pedestrian highways are still rendered as line and not 
as area. Also a rule like highway=* & (type=multipolygon|area=yes) in my 
polygon style does not work. Any ideas?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] multipolygon highway areas (like pedestrian)

[lig fietser]

On my maps those roads were already routable (along the perimeter) only the 
areas were not rendered grey like a square/plaza.


Gerd wrote:
The patch from Andrzej was a bit different.
If I got this right he doesn't want to route over these roads.

What do you think?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] POI indexing, problem with label 0x2800

[lig fietser]

I dont like the idea to remove pois 0x28xx from the index, I use them for many 
items which are searchable! Better make an custom option where you can switch 
indexing on/off.


From: mkgmap-dev  on behalf of Andrzej 
Popowski 
Sent: Thursday, January 19, 2017 6:05:47 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] POI indexing, problem with label 0x2800

Hi,

POI types 0x28xx are usually treated as labels, there is no icon for
these POIs, only label text. CGPSMapper doc describe these POI as
"Region name".

I'd like to use these POI for house numbers. Problem is, that mkgmap
indexes labels! It results in big increment of img files and index file.
I doubt these objects are searchable, probably all this indexing is only
a waste of space.

I have found code in MdrUtils.java, which adds labels to index. I think
this can be removed. And maybe you can add POIs in range 0x64xx -
0x66xx, they probably are searchable.

There is an increase in LBL subfile, I haven't found code responsible
for this. There seems to be a section LBL5 called "POI index", maybe
labels goes there too?

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] POI indexing, problem with label 0x2800

[lig fietser]

Hi Andrzej,
Sorry, maybe you were right. I see now that I also use the continue statement 
to make those pois searchable.
I forgot why I have made two rules for some pois, maybe it is because of this 
issue that garmin couldnt find those 0x28xx that I have added another line in 
the past? I dont like to change my typ files because some users have their own 
customized typ file for my maps.

Andrzej wrote

Hi, on which GPS can you search for labels?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Is smoothness=bad unpaved?

[lig fietser]

Hi list,

On the Garmin OSM forum there is a discussion started whether we should 
consider smoothness=bad as unpaved. In the default rules it is treated as 
unpaved. What do you think?

Should we adapt the rules and skip 'bad' from the unpaved list?

https://forum.openstreetmap.org/viewtopic.php?pid=628555#p628555



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is smoothness=bad unpaved?

[lig fietser]

The problem is that it works too well. Paved roads with some potholes which are 
marked as bad are avoided.

On the forum there is support for skipping smoothness=bad from the list of 
unpaved options, but to add a road_speed penalty instead.


I think of adding this rule after the unpaved rules

highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'  { 
add mkgmap:road-speed = '-2' }






Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: maandag 30 januari 2017 03:10:15
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] Is smoothness=bad unpaved?

I did not try if the rule itself works. If it catches "bad", "very_bad", and 
all worser values I think it is good as it is.

Gerd

____________
Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Montag, 30. Januar 2017 10:07:07
An: mkgmap-dev
Betreff: [mkgmap-dev] Is smoothness=bad unpaved?

Hi list,

On the Garmin OSM forum there is a discussion started whether we should 
consider smoothness=bad as unpaved. In the default rules it is treated as 
unpaved. What do you think?

Should we adapt the rules and skip 'bad' from the unpaved list?

https://forum.openstreetmap.org/viewtopic.php?pid=628555#p628555




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is smoothness=bad unpaved?

[lig fietser]

Thanks Gerd!



Hi,

if I got that right the forum agreed to this, so if nobody complains I'll
change the default
style as suggested on thursday.

Gerd

ligfietser wrote
> The problem is that it works too well. Paved roads with some potholes
> which are marked as bad are avoided.
>
> On the forum there is support for skipping smoothness=bad from the list of
> unpaved options, but to add a road_speed penalty instead.
>
>
> I think of adding this rule after the unpaved rules
>
> highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'
> { add mkgmap:road-speed = '-2' }

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is smoothness=bad unpaved?

[lig fietser]

Another issue that is related to the unpaved rules is posted by Peter 
'Beddhist' on the forum:

https://forum.openstreetmap.org/viewtopic.php?pid=630231#p630231

highway=track & surface=paved is marked as unpaved by mkgmap.

This isssue is caused by this rule:

(highway=bridleway | highway=path | highway=track | highway=unsurfaced)
& surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
{ add mkgmap:unpaved=1 }

If my interpretation is correct, it says that all those types of highway are 
considered as unpaved, unless there is a surface, tracktype, smoothness AND 
sac_scale parameter!


I think  it should add mkgmap:unpaved=1 unless

- surface=paved,asphalt,concrete, etc* OR

- tracktype=grade1

- smoothness and sac_scale?


*) surface values that are paved are mentioned in the wiki: 
http://wiki.openstreetmap.org/wiki/Key:surface




________
Van: mkgmap-dev  namens lig fietser 

Verzonden: maandag 6 februari 2017 01:40:46
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] Is smoothness=bad unpaved?


Thanks Gerd!



Hi,

if I got that right the forum agreed to this, so if nobody complains I'll
change the default
style as suggested on thursday.

Gerd

ligfietser wrote
> The problem is that it works too well. Paved roads with some potholes
> which are marked as bad are avoided.
>
> On the forum there is support for skipping smoothness=bad from the list of
> unpaved options, but to add a road_speed penalty instead.
>
>
> I think of adding this rule after the unpaved rules
>
> highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'
> { add mkgmap:road-speed = '-2' }
<http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is smoothness=bad unpaved?

[lig fietser]

Thanks Andrzej, I got a bit confused there. The issue was caused by the generic 
new typ file that marked the track line type as 'unpaved road' . Should be 
better if I use 'track' or add another label 'paved' to it.

Van: Andrzej Popowski
Verstuurd: dinsdag 7 februari 00:46
Onderwerp: Re: [mkgmap-dev] Is smoothness=bad unpaved?
Aan: Development list for mkgmap

Hi, > If my interpretation is correct, it says that all those types of > 
highway are considered as unpaved, unless there is a surface, > tracktype, 
smoothness AND sac_scale parameter! Rule is OK. If you negate conjunction (by 
use of "unless"), then you should use disjunction of negations: highway is 
unpaved when there is *no* surface and *no* tracktype and ... equivalent: 
highway is unpaved unless there is surface or tracktype or ... -- Best regards, 
Andrzej ___ mkgmap-dev mailing list 
mkgmap-dev@lists.mkgmap.org.uk 
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

It really depends on the user, the region etc.

In my bicycle map I consider fine_gravel cycleways as paved because my users 
are mainly touring cyclists and those paths are (at least in my region) 
excellent for touring. But not suitable for racing bicycles, for them those 
cycleways  are unpaved.


I would suggest to make it unpaved for generic use and use a regular expression 
sytax to catch all combinations. In my OFM I solved this by using


surface ~ 
'.*(ash|bad|clay|cob|compact|dirt|earth|erde|gr|loam|mud|peb|sand|shotter|rock|turf|unpaved).*'




Dave wrote:

But none are "paved" in the usual sense of that word. I would hate to drive on 
a "fine gravel" road, or an ice road, unless I was prepared for it. Even if the 
fine gravel were on top of a compacted substrate it would present a hazard to 
bicycles and motorcycles. I'm not sure I care how a "salt" road is classified - 
I've never seen one let alone driven on one.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

Talking about surface=ice, how do we handle ice_road=yes? Those roads are 
common in the Arctic regions and cross frozen lakes, so only accessible in 
winter. See http://overpass-turbo.eu/s/ls3

In the generic new style map I made those roads unroutable.
https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/generic%20new/lines
highway=* & ice_road=yes { addlabel 'ice road' } [0x10002 resolution 24]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
Since the default style main focus is on motor vehicles I'd suggest to add 
surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
to it, it seems a quite popular tag.


Gerd wrote
This "raining" part is probably what paved/unpaved is about: The surface of a 
paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a paved road 
while it is raining (at least not from dirt which was part of the surface).

Do you agree on that (last sentence)?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

Gerd, 
I suppose you first look if surface=* ? And what if surface is empty?



Gerd wrote:

Anyhow, my impression is that it would be better to change the rule so that it 
checks the known
paved surfaces and assumes that all others mean unpaved.
The current rules are quite old, it was introduced with r1425 and last changed 
with r1489.

Comments?
Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

I prefer v1, some remarks:


Please add paving_stones:30 (6012 cases)


I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and 
give smoothness=bad a road_speed penalty. See 
https://forum.openstreetmap.org/viewtopic.php?id=57179

https://github.com/ligfietser/mkgmap-style-sheets/commit/1950f88900baaff405bab01887d7e7acbab799af




Hi all,

I've created two different patches, both treat surface=cobblestone as paved.
The major difference between v1 and v2 is in the handling of possibly 
conflicting attributes.
For example, I found quite a lot of ways with
highway=track, surface=paved , tracktype=3
in my hometown area.
With v1 and also with unpatched default style this will be treated as unpaved, 
with v2 it is paved.

The logic in v2 is that we first find surface tags which say "road is paved" 
and for those roads
we will never set mkgmap:unpaved=1.

Which one would you prefer?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

Yes, thats what I intended. Thanks for correcting this Gerd.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: woensdag 8 februari 2017 23:10:41
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] [Patch] unpaved roads

The thread suggest different changes. The last one is this:
highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'  { 
add mkgmap:road-speed = '-2' }

I think this will not work as there is no rule to set mkgmap:unpaved=0.
Did you mean mkgmap:unpaved!=1 instead?

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Mittwoch, 8. Februar 2017 19:26:52
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] [Patch] unpaved roads

I prefer v1, some remarks:


Please add paving_stones:30 (6012 cases)


I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and 
give smoothness=bad a road_speed penalty. See 
https://forum.openstreetmap.org/viewtopic.php?id=57179

https://github.com/ligfietser/mkgmap-style-sheets/commit/1950f88900baaff405bab01887d7e7acbab799af




Hi all,

I've created two different patches, both treat surface=cobblestone as paved.
The major difference between v1 and v2 is in the handling of possibly 
conflicting attributes.
For example, I found quite a lot of ways with
highway=track, surface=paved , tracktype=3
in my hometown area.
With v1 and also with unpatched default style this will be treated as unpaved, 
with v2 it is paved.

The logic in v2 is that we first find surface tags which say "road is paved" 
and for those roads
we will never set mkgmap:unpaved=1.

Which one would you prefer?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

I agree to use smoothness only for a speed penalty. I thought I reconized the 
last example that you mentioned, but it was another bad road that I cycled on 
in Romania (pasul Rarau, a few km to the west of your example, was paved and 
horrible, now marked as footpath) [😉]







OK, here is v3 of the patch based on v1.  Changes:
- also treat surface=paving_stones:30 as paved
- treat highway=via_ferrata as unpaved
- don't interpret smoothness=bad as unpaved

Add spead penalty for roads with very_bad or worser smoothness if they are not 
flagged as unpaved
highway=* & mkgmap:unpaved!=1 & smoothness ~ '.*(bad|horrible|impassable)'  { 
add mkgmap:road-speed = '-2' }

I still don't like this version. It sets mkgmap:unpaved=1 for highways which 
are explicitely mapped as paved, e.g.
http://www.openstreetmap.org/way/150436049
which matches
highway=tertiary & surface=paved & smoothness=very_bad
or
http://www.openstreetmap.org/way/38245394

There are quite a lot of major highways with a combination of paved surface and 
ugly smoothness.
I think the smoothness tag should only be used to add a road speed penalty.

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

My OFM will mark them as unpaved. The combination of track and grade3 counts 
more than the surface. I think the current default rules assign them also as 
unpaved. Your patch v3 too, is that correct?



Gerd wrote:

And what about combinations of surface meaning paved with tracktype?
The wiki says "Usually ... " or "Almost always an unpaved track" for most
tracktype values.

I see quite a lot of ways with
highway=track & surface=concrete:lanes & tracktype=grade3
in my Niedersachsen:
http://overpass-turbo.eu/s/lNI

I think those are not unpaved, no matter how nice it is to cycle on them;-)

Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

Good job Gerd,

Two remarks:


mtb:scale=0 can also be used for paved trails. I would suggest not to assume 
this means unpaved if mkgmap:unpaved=0

So better use this rule >0 and 0+


I guess bridleways can be paved too, so also apply this for mkgmap:unpaved!=0



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 9 februari 2017 08:58:58
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] [Patch] unpaved roads

reg. smoothness: the patch contains this line , forgot to comment it
Rule 7:
highway=* & mkgmap:unpaved!=1 & smoothness ~ '.*(bad|horrible|impassable)'  { 
add mkgmap:road-speed = '-2' }

reg. double values: I agree that most of them come from wrongly merged roads.
The patch treats them all as unpaved, the unpatched version treats them like 
paved.
I think the patch makes it more likely that someone will fix the wrong 
value(s), and it is producing fewer
errors.
I see no reason to believe that the first value is better than the 2nd.

Gerd

Von: mkgmap-dev  im Auftrag von 
Alexandre Folle de Menezes 
Gesendet: Donnerstag, 9. Februar 2017 17:45:46
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [Patch] unpaved roads

Great, but now you are not handling smoothness anymore.

Regarding the double values, i would get the first and ignore all the rest.  I 
believe these come from wrongly merging segments with different surfaces, 
there's no way to know which one is correct.

Best regards,

Alexandre

Em 09/02/2017 13:43, Gerd Petermann escreveu:

Okay, attached is v6 (more or less a mixture of v2 and v3)

Some comments:
Rule 1) surface values meaning paved:
highway=* & (surface=asphalt | surface=paved | surface=sett |
surface=concrete | surface=concrete:lanes | surface=concrete:plates |
surface=paving_stones  | surface=cobblestone  |
surface=cobblestone:flattened  | surface=metal  | surface=wood)
{ set mkgmap:unpaved=0 }

Rule 2) tracktype=grade1 without explicit surface implies paved:
highway=* & tracktype=grade1 & surface!=* { set mkgmap:unpaved=0 }

Rule 3) highway which was not set to paved before and has a surface or valid 
tracktype tag is unpaved:
highway=* & mkgmap:unpaved!=0 & (  surface=* |  tracktype ~ 'grade[2-6]')  { 
add mkgmap:unpaved=1 }

Rule 4) highway with mtb:scale or climbing attributes is unpaved, even if 
surface says paved:
highway=* & (
mtb:scale=* |
sac_scale ~ '.*(mountain|alpine)_hiking' |
sport=via_ferrata)
{ set mkgmap:unpaved=1 }
Rule 5) default for hw= path or track is unpaved:
(highway=path | highway=track) & mkgmap:unpaved!=0 { add mkgmap:unpaved=1 }
Rule 6) set special highway types to unpaved even if surface says paved:
(highway=bridleway | highway=unsurfaced | highway=via_ferrata) { set 
mkgmap:unpaved=1 }

I am not 100% sure about hw=bridleway in rule 6. I think horses don't like 
paved ways, so a paved
bridleway is probably a tagging error.

I am quite happy with this.

Does anybody know a good way to handle tags with lists like these?
1) surface=asphalt;paving_stones (all meaning paved)
2) surface=grass;earth (all meaning unpaved)
3) surface=asphalt;sand (mixed)

Taginfo shows that most values containing a semicolon are of type 2 or 3.
Maybe rule 1 should also contain asphalt;paving_stones , asphalt;paved and 
paved;asphalt

Please suggest improvements, else I'll commit this patch on Monday.

Gerd

Von: mkgmap-dev 
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Carlos Dávila 
<mailto:cdavi...@orangecorreo.es>
Gesendet: Donnerstag, 9. Februar 2017 14:02:05
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [Patch] unpaved roads

I would interpret that the other way round. If surface=paved, concrete,
... treat it as paved, no matter what tracktype is. I think tracktype is
very often misinterpreted by mappers, and wiki doesn't clarify it much
either. Additionally, tracktype>1 may be an old tag placed before track
was paved, in the same way that you can find a lot of
highway=residential, tertiary, etc + tracktype=*

El 09/02/17 a las 11:25, lig fietser escribió:



My OFM will mark them as unpaved. The combination of track and grade3
counts more than the surface. I think the current default rules assign
them also as unpaved. Your patch v3 too, is that correct?




Gerd wrote:

And what about combinations of surface meaning paved with tracktype?
The wiki says "Usually ... " or "Almost always an unpaved track" for most
tracktype values.

I see quite a lot of ways with
highway=track & surface=concrete:lanes & tracktype=grade3
in my Niedersachsen:
http://overpass-turbo.eu/s/lNI

I think those are not unpaved, no matter how nice it is to cycle on
them;-)

Gerd

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

Hi Gerd,

Maybe take only mtb:scale>1 into account?


Reg. bridleways, look in the UK, huge numbers of bridleways are tagged with 
surface=paved or surface=asphalt.

So I'd say better only take bridleways into account that don't have 
mkgmap:unpaved=0



Hi ligfietser,

reg. mtb:scale:
both the german and english the wiki for mtb:scale=0 say "Gravel or packed 
earth". I think that means unaved.
But you are right, a lot of ways are tagged mtb:scale=0 &surface=asphalt, i 
also found some with mtb:scale=1
Does that mean that we should better ignore the mtb:scale tag reg. unpaved?

reg. bridleway:
My understanding is that horses don't like to go on paved ways. Do you have an 
example for a paved bridleway?

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roundabouts

[lig fietser]

Gerd,

I have used such approach for my bicycle maps and received quite a few negative 
reports with two routable lines on top of each other, especially near and at 
roundabouts. A lot of devices will crash (completely shut down) so I'd not 
recommend this. In Lambertus' generic new we use an invisible 0x0c line in the 
typ file and after the roundabout rules the junctions are made unroutable so we 
don't have two routable lines on top of each other.


https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/generic%20new/lines



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 12 februari 2017 03:39:45
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] roundabouts

Hi all,

the default style contains these rules for roundabouts:
# Roundabouts
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=3 
road_speed=2 resolution 18]
junction=roundabout & (highway=primary | highway=primary_link) [0x0c 
road_class=3 road_speed=2 resolution 19]
junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c 
road_class=2 road_speed=2 resolution 20]
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c 
road_class=1 road_speed=1 resolution 21]
junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=1 
resolution 21]
junction=roundabout & highway=* [0x0c road_class=0 road_speed=1 resolution 22]

The wanted effect is that the Garmin device/software produces hints like "enter 
roundabout" or "Take the 2nd right onto" ...
The disadvantage is that the roundabout is not rendered.

I replaced all the above rules by
junction=roundabout & highway=* [0x0c road_class=0 road_speed=0 resolution 24 
continue]

I tried this with car + bicycle routing and it seems to give the expected 
results (routing hints and rendered roads).
Also the --check-roundabouts option doesn't complain.

Alternative might be to keep the distinction of road types for better time 
estimation, important point is that
"resoltion 24 continue "
is used.

Comments?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roundabouts

[lig fietser]

Ralf's approach is better, if I would start rebuild my map I would choose to do 
the same, but it will take too much time to rebuilt my map from scratch.


@Gerd, I see now that setting  junction=roundabout {set access=no} after the 
roundabout rules doesn't work at all, do you have any explanation why?


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roundabouts

[lig fietser]

Hi Gerd,

Regarding routable types without a road_speed or road_class attribute: this can 
create other problems when searching for an address along that street, routing 
could cause straight lines on the device. Since it is unlikely that there are 
any addresses on a roundabouts you can ignore those warnings. Those crashes 
that were reported were related to my Style where I have used 0x02 for cycling 
routes on top of routable highways. Both lines were routable and this could 
crash the device, in particular at roundabouts where three routable lines were 
used (02, 0c and normal highways).




Hi lig fietser,

hmm, maybe I was mislead by the results of GPSMapEdit. It seems that it shows 
some
defaults when a line with a routable type is not in the NOD file. So, only the 
type 0xc
line is added to the NOD file, but we also know that it is not good to use 
routable types
without a road_speed or road_class attribute. Maybe that explains the problems?
Note the warnings from check-styles:
Warning: routable type 0x08 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 175
Warning: routable type 0x16 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 232
Warning: routable type 0x060 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 243. Type is overlaid with 0x06
Warning: routable type 0x050 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 250. Type is overlaid with 0x05
Warning: routable type 0x040 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 255. Type is overlaid with 0x04
Warning: routable type 0x030 is used for non-routable line with level 0. This 
may break routing. Style file lines, line 261. Type is overlaid with 0x03

Gerd
<http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roundabouts

[lig fietser]

I don't see the benefit of this, on my devices (oregon 600, old Nüvi) without a 
typ file, 0x0c is rendered as a fat orange line drawn on top of the 0x108.. 
types. In Mapsource it works fine, I agree. AFAIK there is no way to make 0x0c 
invisible without a typ file. I've tried to skip resolution but this didnt work 
either, it is still rendered.



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: maandag 13 februari 2017 00:42:30
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] roundabouts

Hi Andrzej,

yes, works fine without typ file on Mapsource, Basecamp and my Oregon 600 .
I think the default 0xc type looks like 0x06, so we need the overlay for 
tertiary (0x05).

The only one still looking bad is highway=service (0x07). I tried to add extra 
rules for it but It seems that 0x10806 doesn't work.
Maybe you have another idea?

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Sonntag, 12. Februar 2017 20:15:59
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] roundabouts

Hi Gerd,

just have tested following version:

# Roundabouts
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801
resolution 18]

junction=roundabout & (highway=primary | highway=primary_link) [0x0c
road_class=3 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=primary | highway=primary_link) [0x10802
resolution 19]

junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c
road_class=2 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=secondary | highway=secondary_link)
[0x10803 resolution 20]

junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c
road_class=1 road_speed=1 resolution 24 continue]
junction=roundabout & (highway=tertiary | highway=tertiary_link)
[0x10804 resolution 21]

junction=roundabout & highway=minor [0x0c road_class=1 road_speed=1
resolution 21]
junction=roundabout & highway=unclassified [0x0c road_class=1
road_speed=1 resolution 21]
junction=roundabout & highway=* [0x0c road_class=0 road_speed=1
resolution 22]

This adds secondary line for roundabout defined as trunk, primary,
secondary and tertiary only. I think other types will work well enough
with standard rendering. Maybe even tertiary can be standard. Map looks
ok, see attached picture with roundabout rendered as primary (no TYP).

Side note: this is example, where style-option can be used. You can make
this extra lines active in style only when a proper style-option is defined.

--
Best regards,
Andrzej

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] roundabouts

[lig fietser]

I also have looked at real OSM data, it renders the same, unfortunately.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: maandag 13 februari 2017 03:44:09
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] roundabouts

Oops, just recognized that you sample doesn't create a NOD file. No idea if 
that is important.

Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 13. Februar 2017 12:42:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] roundabouts

I did not see that with real OSM data.
Please try to add junction=roundabout because this has an effect on the NOD 
file.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Montag, 13. Februar 2017 12:31:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] roundabouts

Here is a test image from Mapsource (above) and Oregon 600 (below). Both 
without typ file.

I've created 10 lines with the following test style:

highway=1 {name '10801'} [0x10801 resolution 18 continue]
highway=2 {name '10802'} [0x10802 resolution 18 continue]
highway=3 {name '10803'} [0x10803 resolution 18 continue]
highway=4 {name '10804'} [0x10804 resolution 18 continue]
highway=5 {name '10805'} [0x10805 resolution 18 continue]
highway=6 {name '10806'} [0x10806 resolution 18 continue]
highway=7 {name '10807'} [0x10807 resolution 18 continue]
highway=8 {name '10808'} [0x10808 resolution 18 continue]
highway=9 {name '10809'} [0x10809 resolution 18 continue]
highway=10 {name '10800'} [0x10800 resolution 18 continue]
highway=* [0x0c resolution 24]

If you zoom out or take a low resolution, you will see a bigger distinction 
between the types. Once you zoom in at the highest level, all types are 
overruled with 0x0c on my Oregon, and in Mapsource with something like 10805 
(unclassified?). Highways with a major class will be rendered first here. I 
haven't tested other devices, it would't surprise me if they show a different 
behaviour.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] aeroway in default style

[lig fietser]

In my OFM style I use the continue statement for rendering highways and 
is_closed() for detecting areas


aeroway=runway & is_closed()!=true [0x10117 resolution 20 continue with_actions]

aeroway=taxiway & is_closed()!=true [0x10117 resolution 23 continue 
with_actions]


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Parallel major roads to cycleways

[lig fietser]

Interesting idea Gerd but those roads are also arterial connections to get in 
or out of the city so for commuting cyclists essential.

A benefit to have such hook is that I can copy the name of the major highway to 
the parallel cycleway if it lacks a name. This is for address search essential, 
since the major highway is often not routable in my maps.


Another benefit could be that I can force the router to route on those parallel 
and often obligatory cycleways and give a high penalty (lesser road_speed or 
road_class)  for the major highway sections. In OSM those highways often lacks 
a tag bicycle=no or bicycle=use_sidepath where in reality the parallel 
cycleways are obligatory.




Van: mkgmap-dev  namens Dave Swarthout 

Verzonden: donderdag 16 maart 2017 03:40:10
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] Parallel major roads to cycleways

There is a fledgling effort underway here in Chiang Mai to do a similar thing. 
This effort centers around the desirability of a route for bicycling. It deals 
with scenic vs dangerous roads for cycling and the 3 point system it uses might 
be insufficient for your needs but it might be adapted. Worth a look at any 
rate.

https://wiki.openstreetmap.org/wiki/WikiProject_Thailand#Bicycling_tagging_.28currently_for_Chiang_Mai_only.29

Dave

On Thu, Mar 16, 2017 at 5:06 PM, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi,

I just want to share an idea which might be interesting for cycling maps:
In Germany and probably also Austria) many major roads have a parallel cycleway 
close to it, often only separated by a patch of grass or natural=tree_row.
Example: A way with bicycle=designated :
http://www.openstreetmap.org/way/243499929
runs next to highway=primary B213
http://www.openstreetmap.org/way/328470949

I think nearly no cyclist likes to use those ways -- they are just a bit safer 
but still lots of cars are running with 100 km/h next to you --
so I think it would be good to have a way to separate them from other ways 
where no major road is close.

A possible way would be this:
Simiar to the new ResidentialHook which sets the mkgmap:residential tag we 
might implement a
hook which collects major roads and calculates an area around it (maybe 20m on 
both sides).
Each way (maybe only those with highway=* ) could be checked against those 
areas in a way that a rule could
decide to "dislike" a way which is mostly within such an area when the map is 
for cyclists.
I guess bridges and tunnels (or more generally the layer tag) needs special 
handling here.

Questions:
1) Do you think this would good to have?
2) If yes, what kind of information would be needed in the style?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Parallel major roads to cycleways

[lig fietser]

Sorry, no objections there, it's of course up to the map maker if he/she 
decides to give a dislike grade to those roads or not.

Unfortunaltely Garmin does not have a "scenic" option, only an option to prefer 
curvy roads in the devices dedicated to motorcyclists. As you know, in my maps 
I have to misuse toll avoidance to force the route to take cycling routes.


Gerd wrote:
yes, I forgot to point out the possible improvements for address search.
Reg. commuting cyclists: I worked in Munich and for some years I commuted ~10 
km between east and west. At that time I did not have a Garmin but I always 
prefered
ways apart from major roads.
What problem do you see here?

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Parallel major roads to cycleways

[lig fietser]

Yes I think it is in the NT format, I have never seen any mkgmap tag that could 
trigger those narrow trails.



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: vrijdag 17 maart 2017 02:14:38
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] Parallel major roads to cycleways

BTW: Arndt asked in his german post how to use the "narrow trails avoidance" in 
activity routing.
I've never tried that. I always assumed that the Garmin assumes that roads with 
a low road_class are narrow trails.
I don't know any special flag to mark a road as a narrow trail. Maybe this is 
was added in the NT format?

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Freitag, 17. März 2017 10:01:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Parallel major roads to cycleways

Sorry, no objections there, it's of course up to the map maker if he/she 
decides to give a dislike grade to those roads or not.

Unfortunaltely Garmin does not have a "scenic" option, only an option to prefer 
curvy roads in the devices dedicated to motorcyclists. As you know, in my maps 
I have to misuse toll avoidance to force the route to take cycling routes.


Gerd wrote:
yes, I forgot to point out the possible improvements for address search.
Reg. commuting cyclists: I worked in Munich and for some years I commuted ~10 
km between east and west. At that time I did not have a Garmin but I always 
prefered
ways apart from major roads.
What problem do you see here?

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253&mlon=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Address search on device with --x-split-name-index option

[lig fietser]

I think I got the same results on my Oregon 600, so thats why I dont use 
--x-split-name-index



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:15:02
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] Address search on device with --x-split-name-index 
option

Hi all,

not sure how this works on other devices. I have a map containing a part of the 
alps with parts of Germany, Switzerland and France.
On my Oregon 600 when I search for an address I have some dialogs
1) select a country (I select Switzerland)
2) select city or select "search all"
3) Enter Street name. I can type a few characters and press enter. The device 
presents a list of road names matching the selected characters.
4) Last is to enter the house number.  I can leave it empty to search for 
streets.

If I select a city (Feuerthalen)in step 2) everything seems to work fine. It 
lists "Obere Rheingasse" as well as "Rheingasse" when I enter "Rheinga".
If I select "search all" the results are weird. Sometimes I get "no result, 
change search parameters", sometimes results look ok.

When I change the code in mdr20 to ignore the additional entries produced with 
the "--x-split-name-index" option the problem seems to be solved,
I just don't find "Obere Rheingasse" when I search for "Rheingasse".

Does anybody see better results in this case with a map produced  with trunk?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253&mlon=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Contourlines © SRTM-Data / NASA
and Jonathan de Ferranti (viewfinderpanoramas.org)
Disclaimer:
Please note that the software is experimental and
provided "as is," and you use the software at your own risk.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Next issue is the gap.

The gap is only visisble with my OFM styles. Other map styles are ok.

It appears with r3875 and later. Does not appear with r3847. The hole is 
exactly at the junction from the Schijndelseweg where two lanes merge, I think 
mkgmap throws away a connection node? Nothing severe for routing because I dont 
use those roads for routing (non routable lines).


Test file is here:

https://drive.google.com/open?id=0B2FG7SFUssGqQVFJUEV4a3NsZ1k


<https://drive.google.com/open?id=0B2FG7SFUssGqQVFJUEV4a3NsZ1k>


Van: mkgmap-dev  namens lig fietser 

Verzonden: zondag 9 april 2017 02:08:30
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875


Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253&mlon=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Thanks, encoded it with UTF8 and it is now working,  r3660 accepted ANSI coding 
but later releases not anymore?



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 02:13:47
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

okay, that is probably a problem of utf8 enocoding. Your file is not utf8.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 11:08:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253&mlon=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Thanks Gerd, mkgmap-r3890 solved all issues, gap is gone and the small map with 
the default style is visisble again.




Hi Minko,

I think the problem was introduced with r3857. I've reverted those changes in 
r3889. Please check if it also solves the problem with the gap.

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap and MapInstall (OS X)

[lig fietser]

I don't have a Mac but I've relased all my Openfietsmaps with r3908 and until 
now no complaints from Mac users. Could there be a bug since the optimize-index 
merge (r-3968)?


Van: mkgmap-dev  namens jan meisters 

Verzonden: dinsdag 20 juni 2017 09:45:48
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] mkgmap and MapInstall (OS X)

Every several month I render my own europe from geofabrik extract, with OSX 
10.11.6 and a style-sheet based on openfietsmap. Mkgmap output is then 
converted to .gmap with JaVaWa MapConverter and viewed in BaseCamp.

This time, with mkgmap_3972 and splitter_583, the resulting map seems to be ok 
in BaseCamp, but MapInstall rejects to send anything to the device - no tile of 
the map is selectable.

I reproduced this failure with a fresh europe-latest a second time, while a 
smaller extract (Nordrhein-Westfalen) works.
Downgrading to last used mkgmap_3820 solved the problem in MapInstall - the 
rendered europe-output is functional for the whole workflow.

Is this a bug or something new in mkgmap I have to adjust in my style?

Thanks for reading!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with osm2.pleiades.uni-wuppertal.de/?

[lig fietser]

Bernd, better ask Lambertus, he probably wont read this here.


Van: mkgmap-dev  namens Bernd Weigelt 

Verzonden: vrijdag 30 juni 2017 23:20:30
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] problem with osm2.pleiades.uni-wuppertal.de/?

Hi

is there a problem with osm2.pleiades.uni-wuppertal.de or the process to
create new files?

there is only the sea_20170615.tar.bz2 in the directory and the files in
bounds are from 20170608

thx
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank,

Your tool is great, thanks for implementing this. I have tried it on the latest 
OFM Benelux map. The tool is complaining about missing DEM tiles (I've 
downloaded it from 
http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm


I noticed those missing tiles in the Netherlands, it also produces grey empty 
tiles, see

https://www.youtube.com/watch?v=76rScFomSWo




Any idea how to solve this?

Is it also possible to make a DEM map from a direectory with the regular img 
tiles (not the gmap version) and how?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

And how about those missing dem tiles? See

https://s1.postimg.org/197j92hi3z/missing_DEM_data.jpg

[https://s1.postimg.org/197j92hi3z/missing_DEM_data.jpg]


I have downloaded the NASA DEM data from

http://www.javawa.nl/srtm/index.php?lang=en


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Nick
I dont know what you mean, but the missing part is the whole NL above N52.2 and 
also everything western from E5.0
So that means
N53E004.hgt -N53E007.hgt are not processed and also the tiles
N52E004.hgt-N52E007.hgt are missing in the map.
They are available in the DEM folder.


Van: mkgmap-dev  namens osm@pinns 

Verzonden: donderdag 26 oktober 2017 00:43
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option


Hi Minko


If you export a  small section from the openstreetmap area which doesn't have a 
tile then it should

tell you the name of the missing .hgt?


You can then search for it on


https://e4ftl01.cr.usgs.gov/SRTM/

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank,

I used the latest version with--usedummydata but the issues that you can see in 
my video at

https://www.youtube.com/watch?v=76rScFomSWo are still present: grey tiles 
everywhere when zooming in and out and no DEM data north of 52.2 (DEM data is 
available there).

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank, 
You can download the map at http://www.openfietsmap.nl/downloads/bnl_full
I have tested it on the OpenFietsMap(gmap) version with this command:
 
for /D %%i in (100100*.*) do 
("g:\mkgmap\Openfietsmap\versions\test\BuildDEMFile.exe" -d %%i\%%i.DEM 
--hgtpath=%hgtpath% --tre=%%i\%%i.TRE --usedummydata --dlon=0.00027761

Thanks for your help, 
Minko


Frank wrote:

Hi fietser.

that's looking like a unknown special case for my DEM-algorithm.

If possible, please let me know the coordinates of the IMG-Tile (left, 
top, widht, height) and the point distance (--dlon) or the hex-output 
for the zoomlevels at the end of the DEM file.

I try to isolate the faultily subtile and i hope, i find a solution for 
that issue.

Frank
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

I really don't understand why you dont get faulty tiles Frank, 79 of the 141 
tiles have issues, either they render grey or they lack shaded relief! I will 
try --lastcolstd and report it back.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Nick, I can't generate GPS files with DEM, how do you do that?



Van: mkgmap-dev  namens osm@pinns 

Verzonden: maandag 30 oktober 2017 10:10:42
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option

Hi Minko

Do you get the same problems on your gps?


On 30/10/2017 17:02, lig fietser wrote:
> I really don't understand why you dont get faulty tiles Frank, 79 of the 141 
> tiles have issues, either they render grey or they lack shaded relief! I will 
> try --lastcolstd and report it back.
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hmm sounds too complicated. I'm generating the DEM data again, I made a mistake 
in my settings, specifying only 100100*.* tiles but I also have 10101*.* tiles, 
this explains those missing DEM in a lot of tiles 😊 I'm trying now the 
lastcolstd and see of it works.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Frank,

I solved those issues with specifying all the tiles now (100100*.img and 
10101*.img) and lastcolstd,

thanks! I still can't generate a map for the garmin device in Mapsource but I 
guess this issue has not been solved, right?


Van: mkgmap-dev  namens lig fietser 

Verzonden: maandag 30 oktober 2017 11:09:17
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option


Hmm sounds too complicated. I'm generating the DEM data again, I made a mistake 
in my settings, specifying only 100100*.* tiles but I also have 10101*.* tiles, 
this explains those missing DEM in a lot of tiles 😊 I'm trying now the 
lastcolstd and see of it works.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank,

I have not recreate the TDB file. Can you or Nick explain how you do this, can 
you use mkgmap for this?


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank,

Thanks for your tool, but can you explain how to specify those img tiles since 
the gmap folder does not contain any img?

This command does not work obviously:


GmTool.exe --overwrite --input 
g:\mkgmap\Openfietsmap\versions\test\Openfietsmap(BNL).gmap\Product1\1001.img
 --output . 
--mapsource=pid:1;fid:10010;cp:1252;ov:1001.img;tdb:1001.tdb.tdb;noov;notyp;nomdx;nomdr;noinst
 --version=1710 --mapfamilyname="Test" --mapseriesname="Test" 
--description="Test" --routable=1 --highestroutable=24 --maxbits4overview=18 
--hasdem=1 --hasprofile=1 --copyright=*I*



Van: mkgmap-dev  namens Frank Stinner 

Verzonden: woensdag 1 november 2017 10:17
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option

Hi,

if you don't find another tool for processing TDB-file, have a look to
my gmtool. This is only a experimental tool but it do the job. I use
only this tool for creating my test-maps.
Don't forget the GarminCore.dll.

https://github.com/FSofTlpz/GmTool/blob/master/bin/Release/GmTool.exe
https://github.com/FSofTlpz/GmTool/blob/master/bin/Release/GarminCore.dll

gmtool --overwrite --input .img --output .
--mapsource=pid:1;fid:10010;cp:1252;ov:osmmap.img;tdb:osmmap.tdb;noov;notyp;nomdx;nomdr;noinst
--version=1710 --mapfamilyname="Test" --mapseriesname="Test"
--description="Test" --routable=1 --highestroutable=24
--maxbits4overview=18 --hasdem=1 --hasprofile=1 --copyright=*I*

This use infos from all IMG-files with 8 characters in the actual
directory and create a new osmmap.tdb. (See also the (german) help with
gmtool --help)

If anybody want to patch a few bytes in a TDB-file and test the result
of this, he can read and then rewrite this file with gmtool. This
should update the crc.


Frank

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev Info Page
www.mkgmap.org.uk
This is a general development list for mkgmap. To see the collection of prior 
postings to the list, visit the mkgmap-dev Archives.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

Hi Frank,

But my main question/problem with your tool is, there are no img files at all 
in a gmap folder structure, so what do I have to do with this tool? Execute it 
on the "old"format folder with no DEM data? Sorry but to me it is very 
confusing now.


Van: mkgmap-dev  namens Frank Stinner 

Verzonden: donderdag 2 november 2017 10:02:57
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option

Hi,

I believe, the problem is the msdos-mask "1001.img". Don't ask me
why, but for microsoft matches this mask also the file 1001_mdr.img
(see also: dir 1001.img). Unfortunately is it the same with the mask
.img. I think, the best way is, the file 1001_mdr.img
temporarly move to another directory. Then you can use the mask *.img.

Another way is using a namelist in a texfile with the option --inputlist.

By the way: "tdb:1001.tdb.tdb" is probably not really that what you
want.

Frank

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] a new DEM-File Option

[lig fietser]

I'm afraid I don't understand your tools Frank.

I guess I will wait until mkgmap has included the DEM handling.



Van: mkgmap-dev  namens Frank Stinner 

Verzonden: donderdag 2 november 2017 11:57:06
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] a new DEM-File Option

Hi,

i don't now your build-process. But i have installed your original map (without 
the DEM's). After you include the DEM's in this IMG files, create with
gmtool with this NEW IMG's a new TDB.

For the old TDB you get with

gmtool -i 1001.tdb -I 2

the following output:

Datei 'd:\tmp\OpenFietsMap\1001.tdb'
21729 Bytes (21,2 kB, 0,0 MB), letzter Schreibzugriff 28.10.2017 01:43:28
   TDBVersion:  407
   CodePage:1252 (0x04E4)
   Family-ID:   10010 (0x271A)
   Product-ID:  1 (0x0001)
   ProductVersion:  1710 (0x06AE)
   FamilyName:  OpenFietsMap (BNL)
   SeriesName:  OpenFietsMap (Benelux_v28-10-2017)
   Routingfähig:1 (0x01)
   größter Routing-Typ: 24 (0x18)
   mit Contourlinien:   1 (0x01)
   DEM: 0 (0x00)
   niedrigster MapLevel:18 (0x12)
   Beschreibung:Test preview map

   Unknown29:   1 (0x2710)
   Copyright:   [CopyrightInformation, ProductInformationAndPrinting]
Map created with mkgmap-r3908
[CopyrightInformation, ProductInformationAndPrinting]
PROGRAM LICENCED UNDER GPL V2
[CopyrightInformation, ProductInformationAndPrinting]
MAP DATA © OPENSTREETMAP.ORG, MAP LAYOUT © 
OPENFIETSMAP.NL, SRTM DATA © U.S. GEOLOGICAL SURVEY
[CopyrightInformation, ProductInformationAndPrinting]
OPENSTREETMAP.ORG CONTRIBUTORS|SEE: 
HTTP://WIKI.OPENSTREETMAP.ORG/INDEX.PHP/ATTRIBUTION
   Overviewmap:
 Kartenummer:   1001 (0x0098BD90)
 übergeordnet:  0 (0x)
 Beschreibung:  OFM_BNL(28-10-2017)
 Anzeigebereich:Lon 2,373047°..7,382920°, Lat 49,350586°..55,264900°
   Detailkarten:145
 Kartenummer:   10010001 (0x0098BD91)
   übergeordnet:1001 (0x0098BD90)
   Beschreibung:BE-Ieper (10010001)
   Anzeigebereich:  Lon 2,373047°..2,900391°, Lat 50,668945°..50,888672°
   Dateien: 10010001.TRE (38603 Byte), 10010001.RGN (3909498 Byte), 
10010001.LBL (175026 Byte), 10010001.NET (428039 Byte), 10010001.NOD
(714739 Byte)


The main-part is a long list of all mapnumbers/files with the subfiles. It is 
necessary to rebuild this list with the DEM-files with their filesize.
That's why use the NEW IMG's for this.

Frank

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] element type definition as variable

[lig fietser]

My maps also have multiple labels and the same issues. To me it looks like 
Garmin is rendering the order totally random, I cant control it either.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: maandag 27 november 2017 08:42:16
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] element type definition as variable

Hi Enrico,
my understanding is this:
The Garmin Renderer collects at all the labels of the ways in the current view, 
next it starts to calculate possible positions so that
labels don't overlap. If that is true, the position of the label depends on the 
length of the displayed text. I see no way to tell the
Garmin software which label has to come first and I would be surprised if the 
Renderer "understands" that your two lines describe
the same object.

Gerd


Von: mkgmap-dev  im Auftrag von 
demon.box 
Gesendet: Montag, 27. November 2017 17:11:55
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] element type definition as variable

Hi Gerd, I would tell you that Garmin fully and perfectly supports (=display)
what I want and MapSource/BaseCamp too and in my opinion, it looks very good
;-)

The only problem is the order of display of the 2 lines in some cases but I
don't understand why

I don't understand if this problem depends on the id number of the object...

Thanks.

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmtool and TDB

[lig fietser]

Hi Frank,

I get an error message "unbekanntes Argument: 1001.tdb"

with

gmtool -i "g:\mkgmap\Openfietsmap\versions\test\Openfietsmap 
(BNL).gmap\Product1\1001.tdb" -i . --withsubdirs 
--mapsource=new.tdb;noov;notyp;nomdx;nomdr;noinst --hasdem=1 -o 
g:\mkgmap\Openfietsmap\versions\test\


What must be filled in after the second -i argument, you put a dot "." there, 
what does it mean?

And what is the purpose of parameter -o? Is that the folder where you want to 
write the output to?


I'm sorry if my questions sound stupid but I don't get it.



Van: mkgmap-dev  namens Frank Stinner 

Verzonden: dinsdag 28 november 2017 07:07:35
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] gmtool and TDB

Hi all,

i have gmtool a little bit extended in the hope of simpler creation of TDB's.

The main point is, that we have to register a old TDB as input file BEFORE all 
other files. Then take gmtool all possible properties from the old file and 
remove or complete the old subfilelist. If we only have additional DEM's can we 
do:

gmtool -i old.tdb -i . --mapsource=new.tdb;noov;notyp;nomdx;nomdr;noinst 
--hasdem=1 -o .

This should be enough for a map with IMG's. If we have a gmap-style map, we 
need the subfiles in the subdirectorys and we can do:

gmtool -i old.tdb -i . --withsubdirs 
--mapsource=new.tdb;noov;notyp;nomdx;nomdr;noinst --hasdem=1 -o .

Hope it worked.


Frank
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmtool and TDB

[lig fietser]

Hi Frank,

Yes I meant new.tdb, I have changed a lot of file names and paths to check 
where this error came from 😉


It seems to work now! With the fixed tdb I can now send maps from the computer 
to the GPS without errors.  I'll check the maps further, will report it when I 
find something. Thanks for your work!



Van: mkgmap-dev  namens Frank Stinner 

Verzonden: vrijdag 1 december 2017 03:36:45
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] gmtool and TDB

Hi,

i hope, the error message was "unbekanntes Argument: new.tdb".

It's a stupid error from me in the description: please change from 
"--mapsource=new.tdb; ..." to "--mapsource=tdb:new.tdb; ...".

The dot after -i means the actual working directory. If you start gmtool in 
directory "g:\mkgmap\Openfietsmap\versions\test\Openfietsmap 
(BNL).gmap\Product1" this is ok. Then you also don't need the full path for 
your old TDB.

-o defined the output path, in this case only for the new TDB.


Frank
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] regular expression help needed

[lig fietser]

Hi,

I have noticed that this notation seems not to work anymore (I'm sure it worked 
before):


barrier=* & barrier ~ '(lift_gate | toll_booth | border_control | swing_gate | 
log)' [0x3201 resolution 23]


I have a lot like those lines in my style sheets and I dont know why pois like 
barrier=swing_gate is not catched by the line above anymore?


When I add barrier=swing_gate [0x3201 resolution 23] it works as expected.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] regular expression help needed

[lig fietser]

Ah, already found out this syntax contained too many spaces 😉

barrier=* & barrier ~ '(lift_gate|toll_booth|border_control|swing_gate|log)' 
[0x3201 resolution 23]


This one works. Dont know if mkgmap ignored those spaces before though.



Van: mkgmap-dev  namens lig fietser 

Verzonden: woensdag 6 december 2017 05:43:40
Aan: mkgmap-dev
Onderwerp: [mkgmap-dev] regular expression help needed


Hi,

I have noticed that this notation seems not to work anymore (I'm sure it worked 
before):


barrier=* & barrier ~ '(lift_gate | toll_booth | border_control | swing_gate | 
log)' [0x3201 resolution 23]


I have a lot like those lines in my style sheets and I dont know why pois like 
barrier=swing_gate is not catched by the line above anymore?


When I add barrier=swing_gate [0x3201 resolution 23] it works as expected.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] BuildDEMFile: system out of memory

[lig fietser]

lig fietser has shared a OneDrive file with you. To view it, click the link 
below.


<https://1drv.ms/u/s!ApArbaVZkx5rbZCEfL0GVPRjSz8>
[https://r1.res.office365.com/owa/prem/images/dc-jpg_20.png]<https://1drv.ms/u/s!ApArbaVZkx5rbZCEfL0GVPRjSz8>

atlantic_DEM.jpg<https://1drv.ms/u/s!ApArbaVZkx5rbZCEfL0GVPRjSz8>




Hi Frank,

I was running your tool on my Atlantic map and got a system out of memory 
error. The script did continue to build the dem data but in my map a few 
islands in the center of the map were missing DEM data (see the red area in the 
attachment, Sao Miguel on the Azores and La Palma and El Hierro on the Canary 
Islands). Any idea how to solve this issue?


The map OFM_Atlantic(13-10-2017_gmap you can download at

http://www.openfietsmap.nl/downloads/atlantic

DEM tiles I downloaded from http://www.javawa.nl/srtm/index.php?lang=en 
(viewfinder panoramas)

<http://ftp.nluug.nl/pub/maps/openfietsmap/Atlantic/OFM_Atlantic(13-10-2017_gmap).zip>

The command that I used is:

for /D %%i in (34351*.*) do (BuildDEMFile.exe -d %%i\%%i.DEM 
--hgtpath=%hgtpath% --tre=%%i\%%i.TRE --lastcolstd --usedummydata 
--dlon=0.00027761
)


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] BuildDEMFile: system out of memory

[lig fietser]

Hi Nick,

My max-nodes are much higher than yours, I use --max-nodes=180



Van: mkgmap-dev  namens osm@pinns 

Verzonden: zaterdag 9 december 2017 10:28:52
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] BuildDEMFile: system out of memory


Hi Minko

Very strange, when I add DEM to your gmapi files the DEM doesn't show at all, 
even though the files exist.

I noticed that your maxnodes are quite low, ie mine are set at 160,000 and with 
this setting  builddemfile creates the desired dem effect using the canary 
islands pbf

Using your files I noticed  builddemfile creating lots of dem files,containing 
mere  dummyvalues.

I tend to avoid  such files.

Just a thought : perhaps experiment with higher maxnodes?

Nick

On 09/12/2017 17:12, lig fietser wrote:
lig fietser has shared a OneDrive file with you. To view it, click the link 
below.


<https://1drv.ms/u/s%21ApArbaVZkx5rbZCEfL0GVPRjSz8>
[X]<https://1drv.ms/u/s%21ApArbaVZkx5rbZCEfL0GVPRjSz8>

atlantic_DEM.jpg<https://1drv.ms/u/s%21ApArbaVZkx5rbZCEfL0GVPRjSz8>




Hi Frank,

I was running your tool on my Atlantic map and got a system out of memory 
error. The script did continue to build the dem data but in my map a few 
islands in the center of the map were missing DEM data (see the red area in the 
attachment, Sao Miguel on the Azores and La Palma and El Hierro on the Canary 
Islands). Any idea how to solve this issue?


The map OFM_Atlantic(13-10-2017_gmap you can download at

http://www.openfietsmap.nl/downloads/atlantic

DEM tiles I downloaded from http://www.javawa.nl/srtm/index.php?lang=en 
(viewfinder panoramas)


The command that I used is:

for /D %%i in (34351*.*) do (BuildDEMFile.exe -d %%i\%%i.DEM 
--hgtpath=%hgtpath% --tre=%%i\%%i.TRE --lastcolstd --usedummydata 
--dlon=0.00027761
)





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] BuildDEMFile: system out of memory

[lig fietser]

Ah I understand now what you've meant Nick.

Lowering my max-nodes from 1,800.000 to 300.000 nodes solved the problem, 
thanks. Builddemfile couldnt handle the very huge tiles in the ocean , so by 
lowering my max-nodes the map got more tiles and those big ocean tiles became 
smaller, so Builddemfile could process them.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] bug?

[lig fietser]

Hi,

I have added a few hacks on barriers to make more info rendering on my maps. 
Therefore I misuse the housenumber option to make it visible, like barriers:


barrier=* & barrier ~ 
'(gate|entrance|lift_gate|stile|block|cycle_barrier|kissing_gate|toll_booth|turnstile|full-height_turnstile|border_control|swing_gate|log|bump_gate)'
 { add mkgmap:housenumber='(${barrier})' ; add 
mkgmap:street='bicycle:${bicycle}' ; add mkgmap:postal_code='open: 
${opening_hours}' ;  }


In this picture you can see it went wrong somewhere, mkgmap translated the 
value "full-heigth_turnstile" into "Full # Eight_turnstile. So somewhere in the 
code mkgmap:housenumber='(${barrier})'  -h is converted into #.  Is this a bug 
or is this intended?




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug?

[lig fietser]

Thanks guys, I can get around this bug with a simple workaround (replace all 
turn-height_turnstile with turnstile), was just wondering what caused this 
behaviour.


Van: mkgmap-dev  namens Henning 
Scholland 
Verzonden: woensdag 13 december 2017 06:55:48
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] bug?

Hi,
I could imagine, -H can also be a code for # (Hash-Tag). If eight
matches the regex for 8 I would expect it's changed to 8 and the result
would be H8. As Garmin always capitalizes the first letter of each word,
it seems eight is interpreted as normal word and -H is transformed to #.

Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Maps in *.gmap format installation directory

[lig fietser]

You can store the gmap folders anywhere, and make a shortcut of this folder. 
Put this shortcut in the default garmin folder(s) . Or use Javawa GMTK, this 
tool will do that for you.


Van: mkgmap-dev  namens Frank Stinner 

Verzonden: maandag 18 december 2017 08:53:53
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] Maps in *.gmap format installation directory

Or you use %PROGRAMDATA%\GARMIN\Maps\. That should ever be the right place and 
undependent from language or OS.

Frank

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4015 in dem-tdb branch implements --x-overview-dem-dist

[lig fietser]

Hi Gerd,
Thanks for the good work to implement DEM into mkgmap!
I have tested a few tiles, I noticed that BuildDEMFile with--dlon=0.00027761 
has a much more detailed relief than the default values x-dem-dists=5520, 
16560, 44176, 88368 How can I get the same results as with dlon=0.00027761?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] WG: r4015 in dem-tdb branch implements --x-overview-dem-dist

[lig fietser]

Hi, although I use 3" hgt files, 3312 looks much more detailed than 9942?



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 23 december 2017 03:33:30
Aan: Development list for mkgmap
Onderwerp: [mkgmap-dev] WG: r4015 in dem-tdb branch implements 
--x-overview-dem-dist

Hi!
I've just noticed that I replied to Minko instead of the list. Please see below.

Gerd


Von: Gerd Petermann 
Gesendet: Samstag, 23. Dezember 2017 12:04
An: lig fietser
Betreff: AW: [mkgmap-dev] r4015 in dem-tdb branch implements
--x-overview-dem-dist

I am not sure what to think about that.
When you use 3'' hgt files (size is  ~2.8MB) the resolution in that data is 
2^32/(360 * 1200) ~ 9942.
When you use 1'' hgt files (size is  ~26MB) the resolution in that data is 
2^32/(360 * 3600) ~ 3314.
The current implementation in mkgmap interpolates the values found in the hgt 
file. It assumes
continous slope between two points at the same lat, so e.g. if one is 123 and 
the other is 135,
it assumes that a point in the middle is at 129.
I assumed that the Garmin algo does something similar when calculating the 
heights, but maybe it
doesn't.

I did not yet try to find out the best values for dem-dists, so it would be 
good to hear about results.

Gerd

____________
Von: lig fietser 
Gesendet: Samstag, 23. Dezember 2017 11:45:21
An: Gerd Petermann
Betreff: Re: [mkgmap-dev] r4015 in dem-tdb branch implements
--x-overview-dem-dist

Thanks Gerd, the value of 3312 works much better now!


Van: Gerd Petermann 
Verzonden: zaterdag 23 december 2017 02:36:32
Aan: lig fietser
Onderwerp: AW: [mkgmap-dev] r4015 in dem-tdb branch implements 
--x-overview-dem-dist

Hi Minko,

to convert the parms for BuildDEMFile you have to multiply by 2^32/360 :
0.00027761 * 2^32/360  ~ 3312.

Gerd

____________
Von: lig fietser 
Gesendet: Samstag, 23. Dezember 2017 11:30:20
An: Gerd Petermann; Development list for mkgmap
Betreff: Re: [mkgmap-dev] r4015 in dem-tdb branch implements
--x-overview-dem-dist

Hi Gerd,
Thanks for the good work to implement DEM into mkgmap!
I have tested a few tiles, I noticed that BuildDEMFile with--dlon=0.00027761 
has a much more detailed relief than the default values x-dem-dists=5520, 
16560, 44176, 88368 How can I get the same results as with dlon=0.00027761?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

[lig fietser]

Thanks Gerd for implementing the poly option. It solves my issues with large 
ocean tiles too, by drawing a polygon around the (azores) islands I can keep 
the tiles big, the issues of memory errors are solved!

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

[lig fietser]

Hi Gerd,
Is it possible to skip dem processing for some specific tiles, for instance I 
have to add some contour tiles that needs to be processed each time with the 
same mkgmap version (cannot add it as already processed img).
I add them as overlay map on my Benelux map with this statement in my rendering 
process:
mkgmap.args -c %date%\splitter\template.args -c contours\contours.args

If I process it, those contours cause a map failure exception :

SEVERE (MapFailedException): contours\10010201.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
SEVERE (BlockManager): contours\10010202.mp.gz: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): contours\10010202.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
SEVERE (BlockManager): contours\10010204.mp.gz: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): contours\10010204.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048

In my contour.args file I have these lines:

mapname: 10010201
input-file: 10010201.mp.gz
mapname: 10010202
input-file: 10010202.mp.gz
mapname: 10010203
input-file: 10010203.mp.gz
mapname: 10010204
input-file: 10010204.mp.gz

How can I skip these files from DEM processing?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

[lig fietser]

Thanks Gerd, I'll try that.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 4 januari 2018 01:24:51
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

Hi Minko,

one way is to place the dem options in an extra file, e.g. dem-args, and use
mkgmap.args -c contours\contours.args -c dem-args -c 
%date%\splitter\template.args
so that the dem options are not active when the contour files are processed.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Donnerstag, 4. Januar 2018 09:36:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

Hi Gerd,
Is it possible to skip dem processing for some specific tiles, for instance I 
have to add some contour tiles that needs to be processed each time with the 
same mkgmap version (cannot add it as already processed img).
I add them as overlay map on my Benelux map with this statement in my rendering 
process:
mkgmap.args -c %date%\splitter\template.args -c contours\contours.args

If I process it, those contours cause a map failure exception :

SEVERE (MapFailedException): contours\10010201.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
SEVERE (BlockManager): contours\10010202.mp.gz: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): contours\10010202.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
SEVERE (BlockManager): contours\10010204.mp.gz: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): contours\10010204.mp.gz: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048

In my contour.args file I have these lines:

mapname: 10010201
input-file: 10010201.mp.gz
mapname: 10010202
input-file: 10010202.mp.gz
mapname: 10010203
input-file: 10010203.mp.gz
mapname: 10010204
input-file: 10010204.mp.gz

How can I skip these files from DEM processing?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

Gerd, I don't know why but mkgmap >v4025 does not work for my maps anymore.

It is doing hours to compile one tile!


My (experimental) DEM settings are

dem-dists=3312,3312,3312,6628,9942
overview-dem-dist=16560

Map levels:
levels = 0:24, 1:23, 2:22, 3:20, 4:18
overview-levels = 5:17, 6:15, 7:14


v4025 compiles ok, I updated my OFM Alps, Benelux and Germany recently.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 03:09:39
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] r4033: new dem options are now documented

Hi all,

see http://www.mkgmap.org.uk/doc/options
I've added them in a chapter headed "Hill Shading (DEM) options"
This also means that you no longer need the --x- prefix when using r4033 or 
newer.

Please suggest improvements, esp. if you have found rules to determine "good" 
dem-dists values.
If possible I'd like to do the calculations in mkgmap instead of asking each 
user to find out what is good.
Maybe option --dem should be changed to --dem-source before merging to trunk?

I think these are the other open problems now (no particular order):
-- determine optimal block-size to avoid MapFailedExeption with large DEM 
files, if that is too complex we'll change the default from 512 to 2048.
-- find possible encoding error for low resolutions, esp. in overview maps. 
Frank Stinner tries to find a solution for this :-)
-- Problems with java heap when creating large or highly detailed maps:
Zipped files require more heap memory because the current implementation has to 
keep a copy of the unzipped content while unzipped files
are kept in MappedByteBuffers which don't require java heap. On the other hand 
they maybe cause other problems as those reported by Carlos:
http://gis.19327.n8.nabble.com/mkgmap-r4025-implements-x-dem-poly-option-tp5909038p5909257.html
One work around would be to keep the unzipped data in temporary files (more 
I/O), another solution might be to further change the algorithm
so that it doesn't require full random access to all(!) hgt files "touched" by 
the overview map. I've already tried to change that with r4027
so that only some rows are required, but that code is not very elegant. I hope 
I find a better solution for this.
@Frank: I think BuildDEMFile also has this problem, right?
-- The code needs further clean up , javadoc and unit tests.

Thanks for the good feedback so far, I think this will be another big 
improvement if merged into trunk.

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

Hi Gerd, I use -Xmx4000m

All tiles get stuck, doesnt matter which one.

I have tried one of the Benelux, Germany, Canary Islands.


I guess my splitter version is too old??

I have still r-321(2014!). Strange because mkgmap 4025 performed well.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

How can I check that? And why does it go wrong with every random tile?

BTW My max-nodes are 160


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 06:52:32
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Minko,

I don't think that splitter is the problem.
The major change in r4026 was for handling of zipped hgt files. Maybe you have 
an unexpected zip archive ?

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 6. Januar 2018 15:47:06
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Gerd, I use -Xmx4000m

All tiles get stuck, doesnt matter which one.

I have tried one of the Benelux, Germany, Canary Islands.


I guess my splitter version is too old??

I have still r-321(2014!). Strange because mkgmap 4025 performed well.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

BTW my DEM tiles for my Atlantic map are unzipped hgt's so that is not the 
case...



Van: mkgmap-dev  namens lig fietser 

Verzonden: zaterdag 6 januari 2018 06:54:09
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented


How can I check that? And why does it go wrong with every random tile?

BTW My max-nodes are 160


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 06:52:32
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Minko,

I don't think that splitter is the problem.
The major change in r4026 was for handling of zipped hgt files. Maybe you have 
an unexpected zip archive ?

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 6. Januar 2018 15:47:06
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Gerd, I use -Xmx4000m

All tiles get stuck, doesnt matter which one.

I have tried one of the Benelux, Germany, Canary Islands.


I guess my splitter version is too old??

I have still r-321(2014!). Strange because mkgmap 4025 performed well.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

I dont use logging Gerd.

And I saw this behaviour in 4028 and 4033.

Here are some of those o5m tiles, maybe they are too big too handle?

http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/






Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 06:59
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented

Are you sure that r4026 was the first version that did not work for you?

Do you use logging with -Dlog.config=... ? If yes, please try without.

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4033: new dem options are now documented

[lig fietser]

Hi Gerd,

I think you are right, it might be the zipped hgt.

If I use it unzipped there seems no delay.

I posted it here:

http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/




Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 07:48:14
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Minko,

can't reproduce the problem with your 10010001.o5m.
Maybe you use a poly file with --dem-poly ?

Please try to reproduce the problem with 10010001.o5m and a directory 
containing only N50E002.hgt
(as this is the only file needed) and a small set of options (default style)

If you can reproduce the problem please post the options and N50E002.hgt .

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 6. Januar 2018 16:05:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] r4033: new dem options are now documented

I dont use logging Gerd.

And I saw this behaviour in 4028 and 4033.

Here are some of those o5m tiles, maybe they are too big too handle?

http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/






Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 6 januari 2018 06:59
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] r4033: new dem options are now documented

Are you sure that r4026 was the first version that did not work for you?

Do you use logging with -Dlog.config=... ? If yes, please try without.

Gerd
<http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4035 fixes problem with *.hgt.zip files

[lig fietser]

Thanks for the quick fix Gerd!

I have tested a few tiles, seems working as expected with r4035.



Hi Minko,
Since r4027 single zipped hgt files (*.hgt.zip) caused problems, mkgmap 
remembered the wrong name and tried to find the file again and again (silentiy 
and without success) for each
height value needed for the DEM calculation.

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] option --show-profiles and DEM

[lig fietser]

I'm sorry Gerd but you are wrong.

When I have a map merged with contours but without DEM and without 
show-porfiles=1 in my options args file the elevation profile is greyes out and 
not available. Only if I use show-porfiles=1 an altitude profile is available 
when making a route. So please keep this option or make it default.


Van: mkgmap-dev  namens Carlos Dávila 

Verzonden: donderdag 11 januari 2018 00:14:29
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] option --show-profiles and DEM

If you compile a map with contour lines and show-profiles=1 MapSource
does calculate route profile. I've been using a command like the
following for a long time and it worked for me:
java -ea -Xmx4500M -jar mkgmap.jar --output-dir=./tmp --tdbfile --latin1
--code-page=1252 --description="OSM+$CURVAS-$MAPA" --country-name=$PAIS
--country-abbr=$ABR --family-name="OSM+$CURVAS $MAPA" --family-id=3$FID
--product-id=1 --product-version=$VERSION --series-name="OSM+$CURVAS
$MAPA" --area-name="$MAPA" --overview-mapname=$ABR-3$FID
--overview-mapnumber=653${FID}000 --index --road-name-config=$CONFIG
--show-profiles=1 tmp/551${FID}*.img curvas/602${FID}*.img
typ/$ABR-3${FID}.TYP
Where tmp/551${FID}*.img are precompiled regular map tiles and
curvas/602${FID}*.img are precompiled contour lines tiles. The only
issue is MapSource doesn't display contour lines, only height numbers.

El 11/01/18 a las 09:03, Gerd Petermann escribió:
> Hi all,
>
> the help says
> --show-profiles=1
>Sets a flag in tdb file which marks set mapset as having contour
>lines and allows showing profile in MapSource. Default is 0
>which means disabled.
>
> I've tried this with MapSource. My findings:
> The option is not related to contour lines, those are always displayed and 
> height is shown when you select one.
> I found two effects of show-profiles=1:
> 1) The button "Show Profile..." in the Route Properties popup is enabled even 
> if no DEM data is available.
> Without DEM data this button is of no use, the displayed profile is a 
> straight line at height 0.
> 2) With DEM data available Mapsource displays the height in the status line 
> when you hover over a hill-shaded area
> with valid data.
>
> The button "Show Profile..." in the Route Properties popup is always enabled 
> when DEM data is available.
>
> My conclusion:
> The option is useless without DEM data and with DEM data it should default to 
> --show-profiles=1
>
> In other words: I think the option should be removed and the flag should be 
> set depending on the DEM data.
>
> Comments?
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] option --show-profiles and DEM

[lig fietser]

Gerd, you can test it with this tile from the Bremen area.
it has contours (10m distance) but no DEM
http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/49000225.o5m
  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] option --show-profiles and DEM

[lig fietser]

With this test map I can also see the difference in the altitude profiles with 
and without DEM (based on 10m contour interval):
 https://postimg.org/gallery/1huzv3m6m/

Please note that the higher accuracy of the DEM profile does not always reflect 
the elevation in reality, the road beds are always smoothing out the micro 
relief and thus leading to a lower elevation gain/loss when riding/walking this 
track.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] option --show-profiles and DEM

[lig fietser]

--show-profiles=1
Sets a flag in tdb file which enables profile calculation in MapSource 
or
Basecamp based on contour lines.


No, if show-profiles = 1 and DEM data is present, the profile is calculated 
from the DEM data and *not* from the contour lines


If DEM data (see "Hill Shading (DEM) options") is available the flag  changes 
the status line to show the height when you hover over an area with  valid DEM 
data.


Agree

Maybe add a remark that if show-profiles = 0 and DEM data is present, an 
elevation profile is always  available?










Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 11 januari 2018 01:33:00
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] option --show-profiles and DEM

Hi Minko,

thanks for the data. I can confirm now that a profile is shown.
So, I suggest to change the description for the option from
--show-profiles=1
Sets a flag in tdb file which marks set mapset as having contour
lines and allows showing profile in MapSource. Default is 0
which means disabled.
to
--show-profiles=1
Sets a flag in tdb file which enables profile calculation in MapSource 
or
Basecamp based on contour lines.
If DEM data (see "Hill Shading (DEM) options") is available the flag
changes the status line to show the height when you hover over an area 
with
valid DEM data.

OK?
Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] option --show-profiles and DEM

[lig fietser]

Sounds good Gerd, plus mention that 0 is default?


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 11 januari 2018 02:07:39
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] option --show-profiles and DEM

Next try:
--show-profiles=1
Sets a flag in tdb file. The meaning depends on the availability of DEM
data (see "Hill Shading (DEM) options").
Without DEM data the flag enables profile calculation in MapSource or
Basecamp based on information from contour lines.
If DEM data is available the profile is calculated with that 
information and
the flag only changes the status line to show the height when you hover 
over
an area with valid DEM data.

OK?
Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Donnerstag, 11. Januar 2018 10:52:29
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option --show-profiles and DEM

--show-profiles=1
Sets a flag in tdb file which enables profile calculation in MapSource 
or
Basecamp based on contour lines.


No, if show-profiles = 1 and DEM data is present, the profile is calculated 
from the DEM data and *not* from the contour lines


If DEM data (see "Hill Shading (DEM) options") is available the flag  changes 
the status line to show the height when you hover over an area with  valid DEM 
data.


Agree

Maybe add a remark that if show-profiles = 0 and DEM data is present, an 
elevation profile is always  available?










Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: donderdag 11 januari 2018 01:33:00
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] option --show-profiles and DEM

Hi Minko,

thanks for the data. I can confirm now that a profile is shown.
So, I suggest to change the description for the option from
--show-profiles=1
Sets a flag in tdb file which marks set mapset as having contour
lines and allows showing profile in MapSource. Default is 0
which means disabled.
to
--show-profiles=1
Sets a flag in tdb file which enables profile calculation in MapSource 
or
Basecamp based on contour lines.
If DEM data (see "Hill Shading (DEM) options") is available the flag
changes the status line to show the height when you hover over an area 
with
valid DEM data.

OK?
Gerd

<http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading

[lig fietser]

Hi,

Today I uploaded my Benelux map but it shows some  rendering issues when 
zooming in and out. I have compiled it with r-4048


https://www.youtube.com/watch?v=x6FAYUkPdYw

The former versions didnt show this behaviour. I have also changed some dist
settings, maybe this can be the cause?

dem-dists: 3312,6628,9942,13248,44176
overview-dem-dist=88368
dem-poly: bnl_dem.poly

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading

[lig fietser]

Hi Gerd

Last week I have compiled my Benelux/German map with 4025.

That one did a better job, I try to compile it again with 4025 and the last dem 
dist settings.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zaterdag 13 januari 2018 02:13:59
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading

Hi all,

sorry, small correction: The problems look different. With Andrzejs sample only 
the hill shading disappeared, in your video the map disappears.
The problems look similar in the way that they seem to appear at random 
positions while zooming in/out, that's why I guessed that we write unexpected
data and the Garmin software doesn't verify it and produces more or less random 
results.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 13. Januar 2018 11:05:12
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading

Hi Minko,

your video shows exactly the problems that I saw with Andrzejs map before r4048 
:-(
I've noticed that your problems appear on the left side while those in Andrzejs 
map always appeared
at the bottom. I've also noticed that in Garmin maps the DEM bbox overlaps the 
tile bbox on all 4 sides while with mkgmap and
BuildDEMFile the upper left corner is the same. Maybe this should be changed.

Reg. your changes on dist values: Hard to say. I also played with differnt 
dists on Andrzejs sample and the error
changed (appeared at different positions) but never disappeared. Do you still 
have the previous mkgmap.jar?
If yes, please try to find out and let us know the version.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Samstag, 13. Januar 2018 10:46:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading

Hi,

Today I uploaded my Benelux map but it shows some  rendering issues when 
zooming in and out. I have compiled it with r-4048


https://www.youtube.com/watch?v=x6FAYUkPdYw

The former versions didnt show this behaviour. I have also changed some dist
settings, maybe this can be the cause?

dem-dists: 3312,6628,9942,13248,44176
overview-dem-dist=88368
dem-poly: bnl_dem.poly

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] bug in r-4025

[lig fietser]

Hi Gerd,
Users of my Openfietsmap Germany  reported a bug in my maps, one tile was 
missing. Normally something went wrong with splitting (tiles too big) but this 
one was compiled fine as img. However, it didn't render, only the overview map. 
I have compiled it with r-4025. When I compile it with r-4066 there is no 
issue, so it is probably solved but I just mention it. Are you aware of this 
bug?

The o5m file is here:
http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/

Screenshot here:
https://www.facebook.com/photo.php?fbid=975247545973988&set=p.975247545973988&type=3&theater

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug in r-4025

[lig fietser]

Hi Gerd

I used these options:


x-dem: G:\mkgmap\DEM
x-dem-dists: 3312,6628,9942,13248,44176
x-overview-dem-dist=88368


The strange thing is that the img is compiled without errors but not rendered. 
This issue/bug is not happening in r-4066 so I guess it is "solved" but you 
never know.



Hi Minko,

Hard to say without detailed information about the used dem options.
Errors in the dem encoder potentially cause buffer overflows/underruns in 
Garmin software.
Maybe you can post the options used with r4025?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug in r-4025

[lig fietser]

BTW,

If i change it into

x-dem-dists: 9942,9942,9942,13248,44176

the rendering is just fine.





Van: mkgmap-dev  namens lig fietser 

Verzonden: woensdag 24 januari 2018 01:14:28
Aan: mkgmap-dev
Onderwerp: Re: [mkgmap-dev] bug in r-4025


Hi Gerd

I used these options:


x-dem: G:\mkgmap\DEM
x-dem-dists: 3312,6628,9942,13248,44176
x-overview-dem-dist=88368


The strange thing is that the img is compiled without errors but not rendered. 
This issue/bug is not happening in r-4066 so I guess it is "solved" but you 
never know.



Hi Minko,

Hard to say without detailed information about the used dem options.
Errors in the dem encoder potentially cause buffer overflows/underruns in 
Garmin software.
Maybe you can post the options used with r4025?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug in r-4025

[lig fietser]

Hi Gerd,

I have found out that the levels in the option file matters:


These settings are fine if I skip level 23:


levels = 0:24, 1:22, 2:20, 3:18
overview-levels = 4:17, 5:15, 6:14


These go wrong, the gmap file is not compiled:


levels = 0:24, 1:23, 2:22, 3:20, 4:18
overview-levels = 5:17, 6:15, 7:14


Now I have tried 3312 instead of 6628 for the second highest level 23:

x-dem-dists: 3312,3312,9942,13248,44176

Then I got this error:
SEVERE (BlockManager): splitter\49000245.o5m: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): splitter\49000245.o5m: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
Exception in thread "main" java.lang.NegativeArraySizeException
at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.

If I use
x-dem-dists: 3312,9942,9942,13248,44176

No error but not rendered and no gmap.

If I use
x-dem-dists: 9942,9942,9942,13248,44176
Everything is ok.

So maybe I had a wrong values for level 23 which seems fixed by r-4066?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug in r-4025

[lig fietser]

Thanks Gerd for sorting this out!


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: woensdag 24 januari 2018 03:10:15
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] bug in r-4025

Hi Minko,

the blocksize problem was the reason for the change in
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4054
and the new branch auto-block
I think this problem is solved.

Gerd


Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Mittwoch, 24. Januar 2018 11:30:05
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] bug in r-4025

Hi Gerd,

I have found out that the levels in the option file matters:


These settings are fine if I skip level 23:


levels = 0:24, 1:22, 2:20, 3:18
overview-levels = 4:17, 5:15, 6:14


These go wrong, the gmap file is not compiled:


levels = 0:24, 1:23, 2:22, 3:20, 4:18
overview-levels = 5:17, 6:15, 7:14


Now I have tried 3312 instead of 6628 for the second highest level 23:

x-dem-dists: 3312,3312,9942,13248,44176

Then I got this error:
SEVERE (BlockManager): splitter\49000245.o5m: overflowed directory with max 
block 65534, current=65535
SEVERE (MapFailedException): splitter\49000245.o5m: (thrown in 
BlockManager.allocate()) Too many blocks. Use a larger block size with an 
option such as --block-size=1024 or --block-size=2048
Exception in thread "main" java.lang.NegativeArraySizeException
at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.

If I use
x-dem-dists: 3312,9942,9942,13248,44176

No error but not rendered and no gmap.

If I use
x-dem-dists: 9942,9942,9942,13248,44176
Everything is ok.

So maybe I had a wrong values for level 23 which seems fixed by r-4066?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev