Re: [mkgmap-dev] Question on routing difference

[Bernhard Hiller]

Hi all,
we had some discussions on the weirdness of Garmin's routing algorithm
in the past.

In August 2014, I described an example, and popej could give a good
explanation:
https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/thread.html#21825

Beyond that, "newer" Garmin outdoor devices (ehm, my Oregon is from
2013) have "activity routing" which causes odd artifacts even when you
think that you do not use it: it may send a car to a cycleway parallel
to a primary road. or a bicycle onto a motorway. Hence the trick by
ligfietser to use non-routable lines for non-cyclable ways is important.
Perhaps you can find the messages some where on the forum
https://forum.openstreetmap.org/

Regards,
Bernhard

Am 07.06.2022 um 16:16 schrieb 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

Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00"

[Bernhard Hiller]

Hi Gerard,
you can check the elevation contour lines by opening the file generated
by your tool in e.g. JOSM (my take some time when the file is large).
Strange distortions are expected at the borders of the whole set of
input files, but not where input files are adjacent to each other.
Your description seems to hint to a bug when crossing the 0°-meridian. I
do not know how srtm2osm reacts there, it might be worth to try it.

Kind regards,
Bernhard

Am 10.03.2022 um 14:15 schrieb Gerard CATTIAUX:


Hello,

After many hours of time to get a correct knowledge of the most
important tools needed to produce Garmin map, like mkmap, Splitter..
and plenty of hours to develop my own Styles files for mkgmap, I am
now able to produce local maps mainly for Fenix 6x or Garmin 66,
specifically for Trail Running.

That help me also to have a mean to verify immediately all my
contributions to OSM database.

To have the best results for my personal maps, I use altitude data
from Sonny.

https://data.europa.eu/data/datasets/dtm-europe?locale=en

For flat part of the country, I generally generate contour lines with
a 5m space, in lieu of a 10m or 20m space between contours lines.

That choice seems for me a very good choice for as an example "Ile de
France" (Extended Region around Paris), where max altitude are between
150 to 200m.

I recently generate contourlines near La Rochelle in France for a
local zone called "Poitou-Charentes",

http://download.geofabrik.de/europe/france/poitou-charentes.html

but unfortunately, I have artefacts, that I don't have for example in
many other regions of France.

These artefacts are also visible for 5m, 10m and 20m space between
contours lines.

These "artefacts" are described in the pdf files given at this link:

https://drive.google.com/file/d/1uiA51R4Kd_WYsdeTrEtevu2jJ_8aPinH/view?usp=sharing

To generate my contour lines, I use mainly hgt2osm, with hgt files
from Sonny.

Hgt files in the example :

N46W002.zip

N46W001.zip

N46E000.zip

N45W002.zip

N45W001.zip

N45E000.zip

Command line

hgt2osm -g HGT-AFAIRE --MinorDistance=10

Hgt2Osm, 13.11.2017, FSofT

64 Bit-OS: ja

Programmodus 64 Bit: ja

MinorDistance: 10

MediumFactor: 5

MajorFactor: 5

HGT-Verzeichnis: HGT-AFAIRE

Mergefile:

OutputOverwrite: False

Höhenkorrektur: -0.5

MinVerticePoints: 3

MinBoundingbox: 0.0005

Douglas-Peucker: 0.04

1. OSM-ID: -1

mit OSMBound: False

mit OSMBounds: True

mit OSMTimestamp: True

mit OSMVersion:  1

mit OSMVisible:  False

max. Punktanzahl je Weg: 500

mit 'contour_ext'-Tag: True

At first sight, it seems that all these artefacts begin just near a
vertical line situated at W0° 00' 00" / E0° 00' 00"

Any ideas to helps me to solve the problem?

Many thanks

Regards

Gerard Cattiaux



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

Re: [mkgmap-dev] emergency_access_point

[Bernhard Hiller]

Hi Gerd,
the question is not so much where the next emergency access point is,
but its reference number (or name). So that I can tell them e.g.: "we
are in the forest halfway between WI-1234 and RÜD-9876". That's an
information they can make use of.
Regards,
Bernhard

Am 01.08.2021 um 13:05 schrieb Gerd Petermann:

Hi Bernhard,

no idea if there is a good POI type for this. I see no good use case for this 
when you have a Garmin device with you which tells you your position. Why would 
you want to know where the next emergency_access_point is?

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Sonntag, 1. August 2021 12:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] emergency_access_point

Hi all,

"highway=ergency_access_point" (see
https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point
) seems not to be included in our style: only in case of a line (instead
of a point), there's an instruction: delete the highway tag.

But it is a useful feature. In case of an emergency, you'll be asked:
"where are you?" and then ... describing the place to the emergency
service can be complicated: "on a cycle way next to the Rhine river a
couple of kilometers south of the town of ..." is not exact enough.
Unfortunatly, no emergency access point sign was directly at that place.
Finding the name of a road leading to the place helped.

So I think it could be helpful to know the reference number of emergency
access points nearby.
What could be a good Garmin id, so that it is searchable?

Regards,
Bernhard
___
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] emergency_access_point

[Bernhard Hiller]

Hi all,

"highway=emergency_access_point" (see
https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point
) seems not to be included in our style: only in case of a line (instead
of a point), there's an instruction: delete the highway tag.

But it is a useful feature. In case of an emergency, you'll be asked:
"where are you?" and then ... describing the place to the emergency
service can be complicated: "on a cycle way next to the Rhine river a
couple of kilometers south of the town of ..." is not exact enough.
Unfortunatly, no emergency access point sign was directly at that place.
Finding the name of a road leading to the place helped.

So I think it could be helpful to know the reference number of emergency
access points nearby.
What could be a good Garmin id, so that it is searchable?

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

Re: [mkgmap-dev] tile takes very long time to generate

[Bernhard Hiller]

Hi Karl,
some time ago, I stumbled upon a tile which took 2 hours(!) on my machine.
With the "--polygon-file" option, the time could be reduced to less than
100 s.
See the old message in the archive:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026490.html
and the thread "Performance with large files":
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/thread.html#26463
Perhaps the trick helps in your case, too.
Kind regards,
Bernhard

Am 08.03.2021 um 06:53 schrieb 7770:

Hi.

I observe a situation that one of the very first tiles (often the first or the
third) that mkgmap generates takes 20 - 30 minutes to generate, wheres the
others take about 30 seconds each.

The map data produced by splitter is a total of around 700 files with splitter
option --max-nodes=1275000.

sea and bouds are used for mkgmap.

At first i thought i am running low on memory but changing to max-jobs=1
(instead of the possible max of 2) did not make any change.

Is mkgmap doing something specific in the beginning that can explain this long
time generating one of the very first tiles?

I can provide more details, let me know how i can best collect those details
in case i need to set some parameters to have mkgmap to say more about what it
is doing.

Regards
Karl






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

Re: [mkgmap-dev] Device Crash Analysis

[Bernhard Hiller]

That strange behavior may occasionally happen, I experienced that
several times in the past. Updating the maps on the device typically
removes it. Oddly, even updating a map of a totally different region may
help...
Regards,
Bernhard

Am 16.08.2020 um 12:14 schrieb jan meisters:

I recently experienced a crash of my Oregon when passing this s
treet, and reproduced it
several times.
The device ran in tracking mode, no routing involved.

I suspected the bridges on both sides, but found nothing suspicious
concerning my style in OSM. Later simulations on device and BC gave no
errors.
Unfortunately it´s not nearby, so I can´t easily recheck on-site.

What other options do I have for further analysis?

Thanks
Jan


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

Re: [mkgmap-dev] Road speed through urban areas

[Bernhard Hiller]

Hi Ticker,
the speed used for routing depends also on your device.
For road_speed 7, I detected 112 km/h on an Oregon 600, and 132 km/h on
an Oregon 400.
For more details, see my old post on that topic at
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/021620.html

Kind regards,
Bernhard

Am 09.07.2020 um 13:41 schrieb Ticker Berkin:

Hi all

I'm not too fussed about maxspeed:practical; there were no examples in
the British Isles. Comments from other people suggest it is used widely
elsewhere and would be useful.

The motorway rule is for completeness. It might improve travel time
estimation but I've no idea what Garmin uses as the driving speed for
road_speed 7/unlimited; maybe it knows about national speed limits.

Ticker

On Thu, 2020-07-09 at 10:16 +, Gerd Petermann wrote:

Hi all,

reg. maxspeed:practical  I think we should not use disputed tags in
preference to well established tags in the default style.
reg. maxspeed:advisory: I see no problem with that.

What's the purpose of this rule? Is it meant to improve travel time
estimation?
highway=motorway & maxspeed!=* & mkgmap:road-speed-max!=* &
mkgmap:country!=DEU {set mkgmap:road-speed-max=6}

Gerd




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

Re: [mkgmap-dev] Garmin types

[Bernhard Hiller]

Hello ael,
please note that rendering (and also indexing) depends on the specific
Garmin unit and its firmware.
The page https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
shows a list of "point of interest" and their default rendering /
indexing on several device types. It also links to pages for lines and
areas.
It is a little dated, and does not always include the latest devices.
Some where should also be a list for custome types, they are not
available on all devices; unfortunately, I do not have the link to it.
Kind regards,
Bernhard

Am 31.05.2020 um 18:40 schrieb ael:

Perhaps this is not appropriate to post on the development list, but
I am a seeking help in building a style file.

Despite having looked at the style-manual and a great many other places
I could not find even a partial list of the Garmin types without which I
am somewhat at a loss.

I have been using mkgmap for some time with good results, except that
the default style seems to omit cycleways, and perhaps other features
that I have yet to notice.

I suspect that most people use the windows TYPViewer or TYPwiz so avoid
needing an explicit list, but since I am in a Microsoft-free zone, that
is not an option here. I did try to run both under Wine, but the initial
attempts failed.

So far the nearest I have found is the source code from imgsrc. I have
also just checked out the mkgmap source code, and had a quick skim
hoping to find a list there. I was also hoping to see the in-built
styles somewhere which I guess that I have yet to find.

I do think that the style manual really needs to include at least a
partial list (presumably all reverse-engineered) or pointers to where
this can be found.

Can someone provide a link, or otherwise indicate where this is in the
mkgmap source to save me time. Apologies for disturbing proper
development work!

ael




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

Re: [mkgmap-dev] Routing Issue with Garmin Edge 830

[Bernhard Hiller]

Hi Stephan,
what does happen when you change all tracktype=grade4 to grade3 or grade5?
That is, put a line like

tracktype=grade4 {set tracktype=grade3}

(I hope I remember the syntax correctly...)
in your lines file, rather near the top of the file.

Regards,
Bernhard

Am 20.05.2020 um 11:33 schrieb Gerd Petermann:

Hi Stephan,

If you can really reproduce the problem with the default style I  doubt that 
this is related to the type of road.
Are you sure that your device uses the new map?
Maybe there is a tile boundary involved?

What happens when you use that small part of the world (see attached file) and 
create a map for it?
It seems you changed the data in that area 
https://www.openstreetmap.org/changeset/85386678#map=18/50.03413/11.98494
so probably I don't see the data that you used before.
BTW: You really should not change data in OSM to test / fix problems with your 
Garmin unless the data is not correctly mapped.
You can load the attached file in JOSM and change it for testing, e.g. add a 
new POI to verify that your device use the new map.

Gerd


Von: mkgmap-dev  im Auftrag von Stephan 
Warzecha 
Gesendet: Montag, 18. Mai 2020 14:59
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Routing Issue with Garmin Edge 830

Hello,

I am sorry but I have a question better called problem.

my new Garmin Edge 830 ist crashing down, sometimes during navigation. I askes 
this question here because garmin told me that the map must be the problem.
I am working with mkgmap since many years and I built „my own“ map form my 
devices. At my old Garmin Vista Hcx the maps working without problem, also on 
MapSource and Basecamp.

I checked the line file more than hunderet times again and again. Yesterday I 
produced the map only with „route“ option and default style which is comming 
with mkgmap. The map that was built has the same problem. I used differnt 
typ-files to crosscheck if the problem comes from typ-file but no success. I 
also tried older versions of mkgmap, the same no success.

I will try to explain what the problem is:

Mostly ways, taged with highway=track and tracktype=grade4, are affected.

They are part oft he map, and there is no problem while routing on MapSource, 
BaseCamp, Vista usw., but if I create the same route on the garmin edge 830, 
the route is built without any problems, but the violet line (route) has 
interruptions. Whenever I had such a part oft he way in a route the device is 
crashing down while driving the route.

This ist the rule wich is used to create the line for tracktype=grade 4
highway=track & tracktype=grade4 {setaccess 'yes'; set mkgmap:unpaved=yes} 
[0x11 road_class=0 road_speed=1 resolution 23]

I also tried it with different way types (0x01 – 0x12, 0x0e 0x0f etc) also I 
tried differnt spped and road classes.

Next step was to try with all Tracks as the same line, like this…
highway=track & tracktype=* {setaccess 'yes'; set mkgmap:unpaved=yes} [0x11 
road_class=0 road_speed=1 resolution 23

Routing on all ways was possible, but the garmin routing line is broken at the 
ways, which was tracktype 4 before.
Now I have no idea what is happening, the device can´t know that the line was a 
tracktype4, all tracks hast he same name and options.

I will add some pictures to explan what im trying to explain, with my terrible 
english ;0))
An example route with MapSource:

[cid:image005.png@01D62D1F.128DFE60]

The same on Garmin Device Edge 830:
[cid:image004.png@01D62D1F.D9B56C30]

Same Route with my layout in Mapsource:

[cid:image008.png@01D62D22.39C3CE80]

And at the Edge 830:

[cid:image007.png@01D62D20.3DFCCF30]


Now the funny things:

*Garmin Map is working,

*If I delete a affeccted way in Openstreetmap and map it new, also only with 2 
Tags like this:

[cid:image009.png@01D62D21.72342900]

…the mistake is gone. I din´t „correct“ the shown example yet. But I got this 
Problem all over whole germany, there must be an error.

Maybe this is a personal  probelm or mistake, but maybe that others has  the 
same problems. If there is any information what Iam doing wrong or something 
else, please let me kown. There are so many hours Iam searching for a solution.

The maps are built with extract from geofabrik, germany file splittet with 
splitter. I used the newest stable versions.

Also the is more information you need, please lt me know.


Viele Grüße / Best Regards

Stephan Warzecha
Logistic and Workplace Services | Logistic Support| Problem Manager Logistic 
Support

T +49 (0) 6026 9762-6120 | F +49 (0) 6026 9762-6504 | 
stephan.warze...@dpd.de


DPD Deutschland GmbH
Stockstädter Straße 10, 63762 Großostheim, Deutschland | 
dpd.de
Besuchen Sie uns auf Facebook, Instagram 
 und Twitter.

[cid:image002.gif@01D14D54.6725B0D0]



Sitz der Gesellschaft: Aschaffenburg | Reg

Re: [mkgmap-dev] change handling of railway=abandoned

[Bernhard Hiller]

Hi Gerd,
of course, {deletealltags} is a different action: it removes the way
completely. "{add access=no}" just makes it unroutable, but leaves it
visible on the map.

Lte's take a look at the roads in my example (due to changes during the
last couple of hours, be sure to look at last year's version):
- the road to the south-west is a tertiary, without explicit access
tags, and railway=razed:
https://www.openstreetmap.org/way/326001702/history
- the road north-east into Meinershagen is a residential, without
explicit access tags, and railway=razed:
https://www.openstreetmap.org/way/617284819/history
- the road to the east is a primary, without explicit access tags, and
railway=razed:
https://www.openstreetmap.org/way/306731105/history

True, there is another difference: railway=razed is not
railway=abandoned. Can we be sure that all those tags used for
indicating a former railway, like abandoned - dismantled - disused -
razed etc., are always used correctly? I tried an overpass api search
for railway=abandoned and highway=*, but could not find out how to do it
correctly.

If those roads had railway=abandoned instead, they would no more be
routable with your rule. Or is there some catch?

Let's look at some examples showing that railway=abandoned is not always
used so strictly (or are milestones next to the way enough hints for the
former presence of a railway?):
- https://www.openstreetmap.org/way/121395347 has railway=abandoned,
highway=path, with explicit access tags for foot and bicycle. I think
the rule won't cause trouble here.

- https://www.openstreetmap.org/way/130369751 has railway=abandoned,
path=cycleway, and an access tag for foot (but not for bicycle). I think
the rule would then remove the access of bicycles to that cycleway.

- https://www.openstreetmap.org/way/101937226 has not yet been detected
by the historic railway mappers, and lacks any railway tags. The rule
won't do anything here ;-)

https://www.openstreetmap.org/way/561220394 has railway=abandoned,
path=cycleway, and access tags for foot and bicycle. The rule won't
cause trouble here.

We should make sure that "access" won't be removed from highways with
that rule.

Kind regards,
Bernhard



Am 20.01.2020 um 19:49 schrieb Gerd Petermann:

Hi Bernhard,

well, {add access=no} is very different to action {deletealltags}
My thinking is that a railway=abandoned without highway=* still might be used 
as a highway if a tag like foot=yes or bicycle=yes exists.
Tickers idea should have more or less the same effect.

Gerd

____
Von: Bernhard Hiller 
Gesendet: Montag, 20. Januar 2020 19:41
An: Gerd Petermann
Betreff: Re: [mkgmap-dev] change handling of railway=abandoned

Hi Gerd,
"add access=no" is a very dangerous option.
In my style, I added a rule for removing such ways completely. And it
failed terribly - today, there may be public roads on previous railways.
See also my post in the forum at
https://forum.openstreetmap.org/viewtopic.php?id=66451
Kind regards,
Bernhard

Am 18.01.2020 um 19:51 schrieb Gerd Petermann:

Hi all,

the default style has this rule:
# following really should be removed, but see: 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html
railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]

I agree with Ticker that it is not a good idea to make such a way routable. I 
would accept this when it has also a tag like bicycle=s. I found a few ways 
like this, e.g. https://www.openstreetmap.org/way/122268824 (I wonder why 
nobody added a highway tag since 2011)
BUT we should not assume access=s for a railway«andoned. So, what about this:
railway«andoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 22]

Gerd



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

Re: [mkgmap-dev] change handling of railway=abandoned

[Bernhard Hiller]

Hi Gerd,
"add access=no" is a very dangerous option.
In my style, I added a rule for removing such ways completely. And it
failed terribly - today, there may be public roads on previous railways.
See also my post in the forum at
https://forum.openstreetmap.org/viewtopic.php?id=66451
Kind regards,
Bernhard

Am 18.01.2020 um 19:51 schrieb Gerd Petermann:

Hi all,

the default style has this rule:
# following really should be removed, but see: 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html
railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]

I agree with Ticker that it is not a good idea to make such a way routable. I 
would accept this when it has also a tag like bicycle=s. I found a few ways 
like this, e.g. https://www.openstreetmap.org/way/122268824 (I wonder why 
nobody added a highway tag since 2011)
BUT we should not assume access=s for a railway«andoned. So, what about this:
railway«andoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 22]

Gerd



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

Re: [mkgmap-dev] default style improvements

[Bernhard Hiller]

Hi Ticker,

I often travel on bike in "nowhere land", where hotels and restaurants 
are rare. So I think it is good to show both PoIs if a hotel contains a 
restaurant. Of course, it would be more relevant to know how other users 
of OSM Garmin maps think about this topic (I use my own style, so the 
changes to the default style are not relevant for me).


A different point I'd like to suggest is a new line type for unpaved 
highways (which are not tracks). Unpaved public highways may be not very 
common in Europe, but they are rather normal in other areas of the world.
The fact that they are rendered like paved highways makes many mappers 
think that it is useless to add this tag - and the little use of the 
surface tag in turn makes map makers think that it does not matter... 
Clouds of dust caused by other vehicles on that road or getting stuck in 
a muddy quagmire are not great user experiences.
Treating them differently for routing purposes is a good step, but that 
is not such visible to many users.


Regards,
Bernhard

Am 05.01.2019 um 18:18 schrieb Ticker Berkin:

Hi Gerd

I'd tried to get all the optical changes out of the way in the first 2
patches, but I missed a few and it seemed easier to fix them as I
spotted them.

This last patch covered about 25 issues. I think it might take a long
time to go through this process sequentially and, as it involves
changes to just 3 or 4 files, it will be confusing do them in parallel,
with multiple patches outstanding. I don't see any difficulty with
having dialogs in parallel about individual aspects in a patch, based
on my list of topics supplied with the first version of the patch.

Regarding polygons and area tag:

In the following, 'polygon' refers to a directly closed way or ways
from a multipolygon relation.

'lines' can test if is dealing with a polygon with:
... & (is_closed()=true | mkgmap:mp_created=true)

If an element needs to be rendered as a line possibly also a polygon it
needs a [... continue] in 'lines' in case it came from a closed way.

In 'polygons', one cannot assume that the element has not already been
rendered as a line.

The area= tag is for OSM mappers to influence the meaning of polygons;
mkgmap style should never set it.

The treatment of polygons being rendered as lines and/or polygons in
the absence of area=yes/no depends on the tag; for instance:

  aeroway=runway is considered a line unless also has area=yes

  highway=pedestrian always generates a line and, unless area=no, a
polygon. This is the OSM representation of a square/plaza, and, in many
cases, needs the routing given by the edge. The area tag is often
missing, so assumed as yes.

  highway=footway always generates a line and, if area=yes, a polygon.
Again, the edge routing is might be needed. Some mappers use this for
walking area that are joined to other walkways/paths, but it shouldn't
be assumed to this, hence assumption of area=no.

It seems reasonably safe and clearer to omit the polygon test if also
testing area=yes. For instance, in 'lines'

  aeroway=runway & area!=yes {name '${ref}'} [0x27 ...]

in 'polygons' the polygon test is irrelevant anyway, but it needs the
inverse of the additional clause in 'lines'

  aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20]

Obviously, a non-polygon with area=yes doesn't get rendered at all.

Does this adequately explain my changes in this area?


At the moment, only elements with internet_access= can generate
multiple points. In your example of a hotel with a restaurant, I'd
rather have the hotel POI than the restaurant one. Many hotels have
restaurants, but most you wouldn't go out of your way to eat there or
they are often for guests only. The same is true of some of the
amenity/leisure/sport/tourist categories; they are more significant tha
n any restaurant they contain.

I must admit that this is an additional post-justification, I hadn't
thought of this when I moved the rules down.

Multiple POI from a single element, requiring massive reordering of the
sections in 'points' and lots of [... continue]s looks a different
problem that I don't want to address at the moment.

Regards
Ticker

On Sat, 2019-01-05 at 08:43 +, Gerd Petermann wrote:

Hi Ticker,

it would be easier to check if you would not mix simple optical
changes (additional/removed blanks) with functional changes ;)
I'd also prefer smaller patches, each one adressing only one problem.
This makes it easier to discuss the patch.

1) I do not yet understand the changes regarding area=yes and
multipolygons. Can you explain that, please?
2) Why are the rules for food POI moved behind e.g.  tourism=hotel?
  I think you often find OSM objects tagged with both
amenity=restaurant and tourism=hotel,
and I'd prefer to find both. Probably a case for continue ?

Gerd


Von: mkgmap-dev  im Auftrag
von Ticker Berkin 
Gesendet: Donnerstag, 3. Januar 2019 17:52
An: Development list for mkgmap
Betreff: Re: [mkgma

Re: [mkgmap-dev] splitter: option for maximum tile area?

[Bernhard Hiller]

Thanks all,
meanwhile I could generate a map which looks fine in QLandkarte and on 
my Oregon.
I'd like to summarize the findings for those who try to create contour 
lines with srtm2osm and feed them into a Garmin map. I updated the wiki 
page https://wiki.openstreetmap.org/wiki/Srtm2Osm


First of all, it is possible to use srtm2osm with elevation data 
downloaded from Viewfinderpanoramas and unzipped into its cache folder.
In contrast to what one might expect, the folder where the *.hgt files 
must be placed is not the folder indicated with the -d option, but a 
folder "SrtmCache" below it (that's hard coded in the source code of 
srtm2osm).
Next, the default start ids for nodes and ways generated by the program 
is long.MaxValue, which is a reserved value in splitter, thus causing an 
exception (see a previous thread: 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029073.html ). The 
options -firstnodeid 9023372036854775807 -firstwayid 9023372036854775807

(or other high values less than long.MaxValue) remove this issue.
It is important to note that a misspelled option will not cause an error 
message by srtm2osm - that option is merely ignored. So do not feel 
surprised when a problem later on a step later on just happened again, 
though you thought that you changed something before...


Another issue is the unlimited size of ways. In OSM data, ways longer 
than 2000 nodes do likely not exist because the API prevents the upload 
of such long ways. But srtm2osm produced ways with more than a hundred 
thousand nodes. splitter tries to keep ways complete. The long ways lead 
to a slow processing by splitter, and to an extremely inflated size of 
the tiles created by splitter (if the original file and the tiles have 
the same format, the sum of file sizes of the tiles should not be much 
more than the file size of the original file): upto 9 times the original 
size.

There after, mkgmap crashes with an OutOfMemory error.
The solution is to limit the file size with option -maxwaynodes 5000 (or 
an even lower value: the files were still inflated by about a half).


Adding the option --precomp-sea to the splitter options is irrelevant 
for the OutOfMemory exception in mkgmap. Also, the value of the 
--max-nodes splitter option proofed irrelevant for the exception. 
Running mkgmap with --max-jobs=3 instead of 4 was also irrelevant.


But running splitter with a high value of --max-nodes in combination 
with --precomp-sea lead to a different exception in mkgmap:
(MapFailedException): 47120100.osm.pbf: (thrown in 
RoadDef.writeRgnOffsets()) Overflow of the NET1. The tile 
(47120100.osm.pbf) must be split so that there are fewer roads in it
Then, that tile was left empty. I could see this issue with big cities 
(Bangkok, Kuala Lumpur) now, but never experienced it before (I created 
a map of Central Europe with a value of 3 million without precomp-sea - 
absolutely no problem).


I hope this information won't be outdated when some else tries to follow 
these steps.


Kind regards,
Bernhard

Am 31.10.2018 um 22:03 schrieb Bernhard Hiller:

Hi all,
currently a Java OutOfMemory exception prevents me from creating a 
map. I already use option --max-jobs=3 (the machine has 4 physical 
cores) and -Xmx5G (of 8 GB installed). Beyond OSM data, the map 
contains DEM and elevation contour lines.
From the tiles finished and those with a new timestamp but about 0 
bytes length, I can see that mkgmap was rendering tiles 47120005, 
47120006, 47120007 at the time of crash.
Tile 47120005 is extremely large by physical area - some 6° x 5.5° 
(see attached file), covering a lot of the south chinese sea, i.e. 
there are not many actual data in that area.
I guess that the problem arises with that tile. I remember some case 
in the past where a single tile covering such a large area of mainly 
sea caused mkgmap to take an enormous amount of time for rendering - 
also here, mkgmap already spent about 1 hour before crashing.
So I'd like to ask: is there some possibility for limiting the area of 
a tile among the splitter options?

Kind regards,
Bernhard


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

Re: [mkgmap-dev] splitter: option for maximum tile area?

[Bernhard Hiller]

Hi Gerd,
I've uploaded some files:
splitter log: 
https://drive.google.com/open?id=12wsnncNkfwKruEw-4UIgmvddK3E_TxtE

kml: https://drive.google.com/open?id=1UOv_FTtl_pK_Nj126WDFnirhaswnvyfZ
smallest tile: 
https://drive.google.com/open?id=1_yDKKpALKSfiRTiicCrEOYgH1vKmnm4w
largest tile: 
https://drive.google.com/open?id=1aidryuJuhixrJIHHou3sibbBNBpRWJeN

Kind regards,
Bernhard

Am 03.11.2018 um 11:38 schrieb Gerd Petermann:

Hi Bernhard,

please post a link to one of the files produced by splitter. If the sum of file 
sizes is much larger than the input file that means that each file
contains a lot of data that was written to keep ways complete. Maybe srtm2osm 
creates lots of very long ways ?

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Samstag, 3. November 2018 11:25
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Gerd,
contour lines were created with srtm2osm  -step 25 -cat 500 100 25
-large with 3" elevation data downloaded from viewfinderpanoramas.
The mkgmap parameters contain "--add-pois-to-areas", but no
"--add-pois-to-lines" (the splitter parameters contain neither - as Ralf
said).
The style for contour lines is simple:
contour=evation & ele<=0 { delete contour; }
contour=evation & contour_ext=elevation_major  { name
'${ele|conv:m=t}'; } [0x22 level 4]
contour=evation & contour_ext=elevation_medium { name
'${ele|conv:m=t}'; } [0x21 level 2]
contour=evation & contour_ext=elevation_minor  { name
'${ele|conv:m=t}'; } [0x20 level 0]
There are no rules for contours in the points and polygons file. The
options file defines the levels only.

Running splitter on the contour lines file only, creates several pdb
files summing up to 4.5 GB
=the problem is with the contour lines.

Next, I'll try to cut Laos from the contour lines file and create a
contour lines map of Laos only...

Kind regards,
Bernhard

Am 02.11.2018 um 19:31 schrieb Gerd Petermann:

Hi Bernhard,

just a guess: If you use option --add-pois-to-lines and you have a rule in the 
points file which processes ele to add a POI
you may see something like that.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 2. November 2018 19:24
An: Bernhard Hiller; Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

what are your rules for the contour lines?

Gerd

____
Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Freitag, 2. November 2018 19:18
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi all,
still struggling with that strange issue. But I guess I found some hint
to the cause: inconsistent file sizes.
- extracted OSM data: 400 MB pbf
- elevation contour lines: 600 MB pbf
- merged file: 1 GB pbf
So far, sizes are consistent.

When I run splitter on the OSM data only file, it produces many tiles
summing up to some 400 MB. Consistent, too. When I run mkgmap on this
output, I get a map within about half an hour, and it looks OK (tested
with QLandkarte).

When I run splitter on the merged file, the tiles sum up to some 9 GB.
That is 9 times the size I'd expect. mkgmap can render several of those
tiles (but very slowly); and then crashes on one of them with an
OutOfMemory exception.

So I think that the problem is somewhere in those contour lines, either
when merged or alone.
I'll try to create a contour lines only map as the next step to test
this hypothesis.

Kind regards,
Bernhard

Am 01.11.2018 um 09:32 schrieb Gerd Petermann:

Hi Bernhard,

I tried to reproduce the memory problems with tile 47120005. I don't think that 
the sea itself is a problem here, at least not when you use the --precomp-sea 
option. It took only 15 secs to process that tile with asia data from August 
with the default style and typical options for routing etc.
My input file didn't contain SRTM data so I assume this is the reason. Maybe 
you have many contour lines with ele=our data?

Gerd


Von: Gerd Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:49
An: Gerd Petermann; Development list for mkgmap
Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

looked again at the splitter command in your last post. You also use a rather 
high max-nodes value.
Such a high value means that you get rather large tiles and that mkgmap needs 
more memory for each tile
compared to the default 140. Many users use a value near 120.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

Re: [mkgmap-dev] splitter: option for maximum tile area?

[Bernhard Hiller]

Hi Gerd,
contour lines were created with srtm2osm  -step 25 -cat 500 100 25 
-large with 3" elevation data downloaded from viewfinderpanoramas.
The mkgmap parameters contain "--add-pois-to-areas", but no 
"--add-pois-to-lines" (the splitter parameters contain neither - as Ralf 
said).

The style for contour lines is simple:
contour=elevation & ele<=0 { delete contour; }
contour=elevation & contour_ext=elevation_major  { name 
'${ele|conv:m=>ft}'; } [0x22 level 4]
contour=elevation & contour_ext=elevation_medium { name 
'${ele|conv:m=>ft}'; } [0x21 level 2]
contour=elevation & contour_ext=elevation_minor  { name 
'${ele|conv:m=>ft}'; } [0x20 level 0]
There are no rules for contours in the points and polygons file. The 
options file defines the levels only.


Running splitter on the contour lines file only, creates several pdb 
files summing up to 4.5 GB

=> the problem is with the contour lines.

Next, I'll try to cut Laos from the contour lines file and create a 
contour lines map of Laos only...


Kind regards,
Bernhard

Am 02.11.2018 um 19:31 schrieb Gerd Petermann:

Hi Bernhard,

just a guess: If you use option --add-pois-to-lines and you have a rule in the 
points file which processes ele to add a POI
you may see something like that.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 2. November 2018 19:24
An: Bernhard Hiller; Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

what are your rules for the contour lines?

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Freitag, 2. November 2018 19:18
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi all,
still struggling with that strange issue. But I guess I found some hint
to the cause: inconsistent file sizes.
- extracted OSM data: 400 MB pbf
- elevation contour lines: 600 MB pbf
- merged file: 1 GB pbf
So far, sizes are consistent.

When I run splitter on the OSM data only file, it produces many tiles
summing up to some 400 MB. Consistent, too. When I run mkgmap on this
output, I get a map within about half an hour, and it looks OK (tested
with QLandkarte).

When I run splitter on the merged file, the tiles sum up to some 9 GB.
That is 9 times the size I'd expect. mkgmap can render several of those
tiles (but very slowly); and then crashes on one of them with an
OutOfMemory exception.

So I think that the problem is somewhere in those contour lines, either
when merged or alone.
I'll try to create a contour lines only map as the next step to test
this hypothesis.

Kind regards,
Bernhard

Am 01.11.2018 um 09:32 schrieb Gerd Petermann:

Hi Bernhard,

I tried to reproduce the memory problems with tile 47120005. I don't think that 
the sea itself is a problem here, at least not when you use the --precomp-sea 
option. It took only 15 secs to process that tile with asia data from August 
with the default style and typical options for routing etc.
My input file didn't contain SRTM data so I assume this is the reason. Maybe 
you have many contour lines with ele= your data?

Gerd


Von: Gerd Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:49
An: Gerd Petermann; Development list for mkgmap
Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

looked again at the splitter command in your last post. You also use a rather 
high max-nodes value.
Such a high value means that you get rather large tiles and that mkgmap needs 
more memory for each tile
compared to the default 140. Many users use a value near 120.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,
there is no option for this. Do you use option --precomp-sea in splitter? Maybe 
you use --no-trim ?
If that doesn't help you can try to change the values for
private static final int MAX_LAT_DEGREES =
private static final int MAX_LON_DEGREES =
in SplittableDensityArea.java and compile your own version of splitter.

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Mittwoch, 31. Oktober 2018 22:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter: option for maximum tile area?

Hi all,
currently a Java OutOfMemory exception prevents me from creating a map.
I already use option --max-jobs=he machine has 4 physical cores) and
-Xmx5G (of 8 GB installed). Beyond OSM data, the map contains DEM and
elevation contour lines.
   From the tiles finished and those with a new timestamp but about 0
bytes length, I can see th

Re: [mkgmap-dev] splitter: option for maximum tile area?

[Bernhard Hiller]

Hi all,
still struggling with that strange issue. But I guess I found some hint 
to the cause: inconsistent file sizes.

- extracted OSM data: 400 MB pbf
- elevation contour lines: 600 MB pbf
- merged file: 1 GB pbf
So far, sizes are consistent.

When I run splitter on the OSM data only file, it produces many tiles 
summing up to some 400 MB. Consistent, too. When I run mkgmap on this 
output, I get a map within about half an hour, and it looks OK (tested 
with QLandkarte).


When I run splitter on the merged file, the tiles sum up to some 9 GB. 
That is 9 times the size I'd expect. mkgmap can render several of those 
tiles (but very slowly); and then crashes on one of them with an 
OutOfMemory exception.


So I think that the problem is somewhere in those contour lines, either 
when merged or alone.
I'll try to create a contour lines only map as the next step to test 
this hypothesis.


Kind regards,
Bernhard

Am 01.11.2018 um 09:32 schrieb Gerd Petermann:

Hi Bernhard,

I tried to reproduce the memory problems with tile 47120005. I don't think that 
the sea itself is a problem here, at least not when you use the --precomp-sea 
option. It took only 15 secs to process that tile with asia data from August 
with the default style and typical options for routing etc.
My input file didn't contain SRTM data so I assume this is the reason. Maybe 
you have many contour lines with ele=in your data?

Gerd


Von: Gerd Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:49
An: Gerd Petermann; Development list for mkgmap
Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

looked again at the splitter command in your last post. You also use a rather 
high max-nodes value.
Such a high value means that you get rather large tiles and that mkgmap needs 
more memory for each tile
compared to the default 140. Many users use a value near 120.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,
there is no option for this. Do you use option --precomp-sea in splitter? Maybe 
you use --no-trim ?
If that doesn't help you can try to change the values for
private static final int MAX_LAT_DEGREES =5;
private static final int MAX_LON_DEGREES =0;
in SplittableDensityArea.java and compile your own version of splitter.

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Mittwoch, 31. Oktober 2018 22:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter: option for maximum tile area?

Hi all,
currently a Java OutOfMemory exception prevents me from creating a map.
I already use option --max-jobs=(the machine has 4 physical cores) and
-Xmx5G (of 8 GB installed). Beyond OSM data, the map contains DEM and
elevation contour lines.
  From the tiles finished and those with a new timestamp but about 0
bytes length, I can see that mkgmap was rendering tiles 47120005,
47120006, 47120007 at the time of crash.
Tile 47120005 is extremely large by physical area - some 6° x 5.5° (see
attached file), covering a lot of the south chinese sea, i.e. there are
not many actual data in that area.
I guess that the problem arises with that tile. I remember some case in
the past where a single tile covering such a large area of mainly sea
caused mkgmap to take an enormous amount of time for rendering - also
here, mkgmap already spent about 1 hour before crashing.
So I'd like to ask: is there some possibility for limiting the area of a
tile among the splitter options?
Kind regards,
Bernhard
___
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] splitter: option for maximum tile area?

[Bernhard Hiller]

Hi Gerd,
thanks a lot for your many hints.
The file contains contour lines with ele=0, but I do not know how many. 
Anyway, the style ignores contour lines at an elevation of 0.
Currently, I do not use the --precomp-sea option, but 
"--generate-sea=multipolygon,extend-sea-sectors,floodblocker". Are the 
precompiled coast line files OK again (I remember that they were broken 
just recently)?
Changing the source code of splitter is not an option for me: I have no 
Java IDE installed on my machine.

I'll try now with a severely reduced max-nodes value.
Kind regards,
Bernhard

Am 01.11.2018 um 09:32 schrieb Gerd Petermann:

Hi Bernhard,

I tried to reproduce the memory problems with tile 47120005. I don't think that 
the sea itself is a problem here, at least not when you use the --precomp-sea 
option. It took only 15 secs to process that tile with asia data from August 
with the default style and typical options for routing etc.
My input file didn't contain SRTM data so I assume this is the reason. Maybe 
you have many contour lines with ele=in your data?

Gerd


Von: Gerd Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:49
An: Gerd Petermann; Development list for mkgmap
Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,

looked again at the splitter command in your last post. You also use a rather 
high max-nodes value.
Such a high value means that you get rather large tiles and that mkgmap needs 
more memory for each tile
compared to the default 140. Many users use a value near 120.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 31. Oktober 2018 22:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area?

Hi Bernhard,
there is no option for this. Do you use option --precomp-sea in splitter? Maybe 
you use --no-trim ?
If that doesn't help you can try to change the values for
private static final int MAX_LAT_DEGREES =5;
private static final int MAX_LON_DEGREES =0;
in SplittableDensityArea.java and compile your own version of splitter.

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Mittwoch, 31. Oktober 2018 22:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter: option for maximum tile area?

Hi all,
currently a Java OutOfMemory exception prevents me from creating a map.
I already use option --max-jobs=(the machine has 4 physical cores) and
-Xmx5G (of 8 GB installed). Beyond OSM data, the map contains DEM and
elevation contour lines.
  From the tiles finished and those with a new timestamp but about 0
bytes length, I can see that mkgmap was rendering tiles 47120005,
47120006, 47120007 at the time of crash.
Tile 47120005 is extremely large by physical area - some 6° x 5.5° (see
attached file), covering a lot of the south chinese sea, i.e. there are
not many actual data in that area.
I guess that the problem arises with that tile. I remember some case in
the past where a single tile covering such a large area of mainly sea
caused mkgmap to take an enormous amount of time for rendering - also
here, mkgmap already spent about 1 hour before crashing.
So I'd like to ask: is there some possibility for limiting the area of a
tile among the splitter options?
Kind regards,
Bernhard
___
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] DEM and SRTM hgt files: size too small

[Bernhard Hiller]

Hi Thorsten,
viewfinderpanoramas provides files for that area too. Download cells M32 
and M33 from

http://www.viewfinderpanoramas.org/Coverage map viewfinderpanoramas_org3.htm
The unzipped files all have a size of 2818 kb, and work well with mkgmap.
Kind regards,
Bernhard

Am 01.11.2018 um 10:16 schrieb Thorsten Kukuk:

Hi,

I started to play with maps with DEM, but run into a problem:
viewfinderpanoramas.org provides hgt files, but only for some areas.
The SRTM1v3.0 data is using geotiff. No problem, you can convert them
with gdal_translate and fill the missing areas. Works fine for below N50,
but starting with N50, the data is much smaller and this leads to the
following error:
SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E012.hgt has 
unexpected size 12970802 and is ignored
SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E013.hgt has 
unexpected size 12970802 and is ignored
SEVERE (HGTReader): 71200159.osm.pbf: file /data/OSM/data/hgt/N50E014.hgt has 
unexpected size 12970802 and is ignored

Any ideas how to solve the problem?

   Thorsten



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

[mkgmap-dev] splitter: option for maximum tile area?

[Bernhard Hiller]

Hi all,
currently a Java OutOfMemory exception prevents me from creating a map. 
I already use option --max-jobs=3 (the machine has 4 physical cores) and 
-Xmx5G (of 8 GB installed). Beyond OSM data, the map contains DEM and 
elevation contour lines.
From the tiles finished and those with a new timestamp but about 0 
bytes length, I can see that mkgmap was rendering tiles 47120005, 
47120006, 47120007 at the time of crash.
Tile 47120005 is extremely large by physical area - some 6° x 5.5° (see 
attached file), covering a lot of the south chinese sea, i.e. there are 
not many actual data in that area.
I guess that the problem arises with that tile. I remember some case in 
the past where a single tile covering such a large area of mainly sea 
caused mkgmap to take an enormous amount of time for rendering - also 
here, mkgmap already spent about 1 hour before crashing.
So I'd like to ask: is there some possibility for limiting the area of a 
tile among the splitter options?

Kind regards,
Bernhard


splitter.kml
Description: application/vnd.google-earth.kml
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this value is reserved"

[Bernhard Hiller]

Hi Gerd,
Please find enclosed file "splitter.log" which shows node ids in that 
region:

10.000.000 nodes parsed... id=9223372036671913720
splitter crashes after the entry
190.000.000 nodes parsed... id=9223372036851913720

The source code of srtm2osm at 
https://svn.openstreetmap.org/applications/utils/Srtm2Osm/trunk/Srtm2Osm/Srtm2OsmCommand.cs 
shows that


private long firstNodeId = long.MaxValue;

is the default value, the source of the IdCounter shows that it does 
decrement for the further values by default.

=> The value comes from the generation of contour lines via srtm2osm.
By the way, also firstWayId is initialized to long.MaxValue. Would that 
also cause problems with splitter?


Strange that this fact did not cause problems in February, when I 
created a map of Taiwan with DEM and elevation contour lines. Perhaps a 
bounding box in an osmosis command happened to remove this node id by 
chance.


So, I guess, we have a solution. The bad thing is: I'll have to re-run 
the generation of the contourlines file with srtm2osm (with additional 
parameters for first node and way ids), which takes several hours, plus 
1 hour of sorting, 


Kind regards,
Bernhard

Am 29.10.2018 um 08:04 schrieb Gerd Petermann:

Hi Bernhard,

splitter cannot store the id values 0 and 9223372036854775807 (which is 
Long.MAX_VALUE)
No idea why your process whould create an id with such a value, looks like an 
error to me.
The following message about the sort is misleading :-(

Do you have an idea where this id comes from?

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Montag, 29. Oktober 2018 07:48:02
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this 
value is reserved"

Hi all,
I tried to create a map of south east asia with contourlines. DEM data
are from Viewfinderpanoramas, and were processed with srtm2osm. It took
7 h to generate a 40GB *.osm file, and another 1 hour to sort the data
with osmosis into a 600 MB *.pbf file. A region from 0-23N and 94-109E
was cut from the asia extract from Geofabrik with osmosis (some 400 MB).
These two files were combined with osmosis.

When I call splitter on that file, I get the error message:

Error: Cannot store node id 9223372036854775807, this value is reserved.
uk.me.parabola.splitter.SplitFailedException: Maybe the IDs are not
sorted. This is not supported with keep-complete=ue or --problem-list
  at
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:508)
  at
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
  at
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
  at
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
  at
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)
  at uk.me.parabola.splitter.Main.useProblemLists(Main.java:487)
  at uk.me.parabola.splitter.Main.start(Main.java:125)
  at uk.me.parabola.splitter.Main.main(Main.java:79)

The splitter command is:
E:\Maps\Development\Thai.1>"C:\Program
Files\Java\jre1.8.0_121\bin\java.exe" -Xmx6G -jar  "C:\Program Files
(x86)\OpenStreetMap\splitter-r590\splitter.jar"
E:\Maps\Raw\SouthEastAsia_Complete.osm.pbf --description=ernieMap Bike
Thai" --mapidG120001 --max-nodes 0 --max-threads=4
--write-kml=slitter.kml--no-trim  1>splitter.log

Do I need to sort again after merging? Or is that a different issue?
Thanks a lot for your hints.

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



Splitter version 590 compiled 2018-01-27T09:06:04+
boundary-tags=use-exclude-list
cache=
description=BernieMap Bike Thai
geonames-file=
handle-element-version=remove
ignore-osm-bounds=false
keep-complete=true
mapid=47120001
max-areas=2048
max-nodes=300
max-threads=4
mixed=false
no-trim=true
num-tiles=
output=pbf
output-dir=
overlap=auto
polygon-desc-file=
polygon-file=
precomp-sea=
problem-file=
problem-report=
resolution=13
search-limit=20
split-file=
status-freq=120
stop-after=dist
wanted-admin-level=5
write-kml=splitter.kml
Elapsed time: 0s   Memory: Current 123MB (5MB used, 118MB free) Max 5461MB
Time started: Mon Oct 29 19:06:16 CET 2018
Map is being split for resolution 13:
 - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
 - areas are multiples of 0x800 map units wide and high
Processing E:\Maps\Raw\Thai.DEM\SouthEastAsia_Ele.osm.pbf
10.000.000 nodes parsed... id=9223372036671913720
20.000.000 nodes parsed... id=9223372036681913720
30.000.000 nodes parsed... id=9223372036691913720
40.000.000 nodes parsed... id=9223372036701913720
50.000.000 nodes par

Re: [mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this value is reserved"

[Bernhard Hiller]

Hi Gerd,
I am investigation the origin of that id.
I tried to run splitter on the file generated by srtm2osm. After half an 
hour, I got following exception:
E:\Maps\Development\Thai.1>"C:\Program 
Files\Java\jre1.8.0_121\bin\java.exe" -Xmx6G -jar  "C:\Program Files 
(x86)\OpenStreetMap\splitter-r590\splitter.jar" 
E:\Maps\Raw\Thai.DEM\SouthEastAsia_Ele_Unsorted.osm 
--description="BernieMap  Bike Thai" --mapid=47120001 
--max-nodes=300 --max-threads=4 --write-kml=splitter.kml 
--no-trim  1>splitter.log

Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.
This is not supported with keep-complete=true or --problem-list
uk.me.parabola.splitter.SplitFailedException: Node ids are not sorted
at 
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:501)
at 
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
at 
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
at 
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
at 
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)

at uk.me.parabola.splitter.Main.useProblemLists(Main.java:487)
at uk.me.parabola.splitter.Main.start(Main.java:125)
at uk.me.parabola.splitter.Main.main(Main.java:79)
which is OK, because srtm2osm does not write its output in some sorted way.

Next, I tried to run splitter on the file produced by osmosis after 
sorting. Now, it did not take long to get the exception:
E:\Maps\Development\Thai.1>"C:\Program 
Files\Java\jre1.8.0_121\bin\java.exe" -Xmx6G -jar  "C:\Program Files 
(x86)\OpenStreetMap\splitter-r590\splitter.jar" 
E:\Maps\Raw\Thai.DEM\SouthEastAsia_Ele.osm.pbf --description="BernieMap 
Bike Thai" --mapid=47120001 --max-nodes=300 --max-threads=4 
--write-kml=splitter.kml--no-trim  1>splitter.log

Error: Cannot store node id 9223372036854775807, this value is reserved.
uk.me.parabola.splitter.SplitFailedException: Maybe the IDs are not 
sorted. This is not supported with keep-complete=true or --problem-list
at 
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:508)
at 
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
at 
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
at 
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
at 
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)

at uk.me.parabola.splitter.Main.useProblemLists(Main.java:487)
at uk.me.parabola.splitter.Main.start(Main.java:125)
at uk.me.parabola.splitter.Main.main(Main.java:79)

That is, the wrong node id exists in the file of sorted elevation data. 
I cannot find out if osmosis or srtm2osm produced that node id.


Kind regards,
Bernhard

Am 29.10.2018 um 08:04 schrieb Gerd Petermann:

Hi Bernhard,

splitter cannot store the id values 0 and 9223372036854775807 (which is 
Long.MAX_VALUE)
No idea why your process whould create an id with such a value, looks like an 
error to me.
The following message about the sort is misleading :-(

Do you have an idea where this id comes from?

Gerd

________
Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Montag, 29. Oktober 2018 07:48:02
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this 
value is reserved"

Hi all,
I tried to create a map of south east asia with contourlines. DEM data
are from Viewfinderpanoramas, and were processed with srtm2osm. It took
7 h to generate a 40GB *.osm file, and another 1 hour to sort the data
with osmosis into a 600 MB *.pbf file. A region from 0-23N and 94-109E
was cut from the asia extract from Geofabrik with osmosis (some 400 MB).
These two files were combined with osmosis.

When I call splitter on that file, I get the error message:

Error: Cannot store node id 9223372036854775807, this value is reserved.
uk.me.parabola.splitter.SplitFailedException: Maybe the IDs are not
sorted. This is not supported with keep-complete=ue or --problem-list
  at
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:508)
  at
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
  at
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
  at
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
  at
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)
  at uk.me.parabola.splitter.Main.useProblemLists(Main.java:487)
  at uk.me.parabola.splitter.Main.start(Main.java:125)
  at

[mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this value is reserved"

[Bernhard Hiller]

Hi all,
I tried to create a map of south east asia with contourlines. DEM data 
are from Viewfinderpanoramas, and were processed with srtm2osm. It took 
7 h to generate a 40GB *.osm file, and another 1 hour to sort the data 
with osmosis into a 600 MB *.pbf file. A region from 0-23N and 94-109E 
was cut from the asia extract from Geofabrik with osmosis (some 400 MB). 
These two files were combined with osmosis.


When I call splitter on that file, I get the error message:

Error: Cannot store node id 9223372036854775807, this value is reserved.
uk.me.parabola.splitter.SplitFailedException: Maybe the IDs are not 
sorted. This is not supported with keep-complete=true or --problem-list
at 
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:508)
at 
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
at 
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
at 
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
at 
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)

at uk.me.parabola.splitter.Main.useProblemLists(Main.java:487)
at uk.me.parabola.splitter.Main.start(Main.java:125)
at uk.me.parabola.splitter.Main.main(Main.java:79)

The splitter command is:
E:\Maps\Development\Thai.1>"C:\Program 
Files\Java\jre1.8.0_121\bin\java.exe" -Xmx6G -jar  "C:\Program Files 
(x86)\OpenStreetMap\splitter-r590\splitter.jar" 
E:\Maps\Raw\SouthEastAsia_Complete.osm.pbf --description="BernieMap Bike 
Thai" --mapid=47120001 --max-nodes=200 --max-threads=4 
--write-kml=splitter.kml--no-trim  1>splitter.log


Do I need to sort again after merging? Or is that a different issue?
Thanks a lot for your hints.

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

Re: [mkgmap-dev] routing between different maps

[Bernhard Hiller]

Hi Andrzej,
I doubt that it is possible.
The extracts from Geofabrik overlap at the administrative borders. So a 
road from e.g. Germany to Poland won't end at the border, but extend a 
few meters (sometimes even kilometers!) into the neighboring country. 
And that holds true for that road in the other direction too.
This means that the common nodes do already exist, but never did 
cross-border routing work (note that I changed my toolchain and generate 
maps containing a few countries because of those issues since a couple 
of years - I cannot be sure if things have changed meanwhile).

Or did I misunderstand the "external nodes"?
Kind regards,
Bernhard
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] DEM bug at 50°N

[Bernhard Hiller]

Hi Gerd,

thanks, that patch works.
Bugs with simple reasons are often hard to find.

The names of the viewfinderpanoramas file look like:
- floor(Longitude/6)+31 for the number part
- (char))floor(latitude/4)+65) for the character at northern latitudes,
- 'S'+(char)(floor(latitude/4)+65) for the character at southern latitudes,
and some exceptions for Greenland, Iceland, and Antarctica.

Kind regards,
Bernhard

Am 11.04.2018 um 09:49 schrieb Gerd Petermann:

Hi Bernhard,

it turned out to be a stupid error in my code, see
http://www.mkgmap.org.uk/websvn/revision.php?repname=gmap&revA54
Please use r4154 (overlaps branch) or r4155 from trunk.

I did not notice this because I never used the zipped files from viewfinder 
because their names (e.g. m32.zip) give
so little information about the content :-(

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 11. April 2018 09:23:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] DEM bug at 50°N

Hi Bernhard,

I think the problem is that the zip files are not in one of the expected 
formats. You should see better results if you unzip the files.
I'll try to add support for this format now.

Gerd


Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Sonntag, 8. April 2018 20:40:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] DEM bug at 50°N

According to the DEM in the map, the Rhine river some 3 km away from my
home is at an elevation of some 2600 m asl. I do not live in the Swiss
alps, but some 50km west of Frankfurt, just north of 50°N... The correct
elevation is about 80m.
Near Bingen (just south of 50°N), the Rhine is at an elevation of ~500m,
somewhere between Assmannshausen and Lorch it ascends suddenly and very
steeply to almost 3000m. In Cologne still at 500 m asl.
South of 48°N, the data seem OK; but in the north, I did not find
reasonable values - the Elbe in Hamburg above 1000m asl.

I exclude a problem in the DEM data: before creating the map of Germany
and Czechia, I tested with Hessen only. And then, the DEM values looked
reasonable.

I use mkgmap 4143. The command includes parameters for DEM:
  --dem-poly=eas.poly ^
  --dem=EMPATH% ^
  --dem-dists314,4000,6000,8000,1,15000,2,3 ^
areas.poly were created by splitter in the step before,
SET
DEMPATH=\Maps\Development\SRTM\L32.zip,E:\Maps\Development\SRTM\M32.zip,E:\Maps\Development\SRTM\N32.zip,E:\Maps\Development\SRTM\L33.zip,E:\Maps\Development\SRTM\M33.zip,E:\Maps\Development\SRTM\N33.zip
contains DEM data from
http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm
(while testing with Hessen, %DEMPATH% was
E:\Maps\Development\SRTM\M32.zip only which contains data from N48E006
to N51E011).

Or is it a matter of file size? The largest *.img file has 131256kB.

Kind regards,
Bernhard
___
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] DEM bug at 50°N

[Bernhard Hiller]

According to the DEM in the map, the Rhine river some 3 km away from my 
home is at an elevation of some 2600 m asl. I do not live in the Swiss 
alps, but some 50km west of Frankfurt, just north of 50°N... The correct 
elevation is about 80m.
Near Bingen (just south of 50°N), the Rhine is at an elevation of ~500m, 
somewhere between Assmannshausen and Lorch it ascends suddenly and very 
steeply to almost 3000m. In Cologne still at 500 m asl.
South of 48°N, the data seem OK; but in the north, I did not find 
reasonable values - the Elbe in Hamburg above 1000m asl.


I exclude a problem in the DEM data: before creating the map of Germany 
and Czechia, I tested with Hessen only. And then, the DEM values looked 
reasonable.


I use mkgmap 4143. The command includes parameters for DEM:
--dem-poly=areas.poly ^
--dem=%DEMPATH% ^
--dem-dists=3314,4000,6000,8000,1,15000,2,3 ^
areas.poly were created by splitter in the step before,
SET 
DEMPATH=E:\Maps\Development\SRTM\L32.zip,E:\Maps\Development\SRTM\M32.zip,E:\Maps\Development\SRTM\N32.zip,E:\Maps\Development\SRTM\L33.zip,E:\Maps\Development\SRTM\M33.zip,E:\Maps\Development\SRTM\N33.zip
contains DEM data from 
http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm
(while testing with Hessen, %DEMPATH% was 
E:\Maps\Development\SRTM\M32.zip only which contains data from N48E006 
to N51E011).


Or is it a matter of file size? The largest *.img file has 131256kB.

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

Re: [mkgmap-dev] Error building DEM map

[Bernhard Hiller]

Hi Carlos,
I remember that mkgmap takes very long when there are some strange large 
tiles which are almost empty (or contain large almost empty areas). I 
could solve that by cutting the desired area from the input file before 
running splitter.
I do not know if this is applicable in your situation, too. You might 
look into the "areas" file generated by splitter: if there is such a 
strange large area, try the trick.

Regards,
Bernhard

Am 27.02.2018 um 23:06 schrieb Carlos Dávila:
I'm facing an error compiling Algeria map with DEM, using SRTM1 hgt 
files. In a first run I use splitter as follows: java -Xmx6G -jar 
splitter.jar --max-nodes 0 
--geonames-file=onames/cities15000_$ABR.zip --mapidU1${FID}001 
--output=m algeria.o5m
It gives 5 tiles and when I run mkgmap on them [1], it takes a very 
long time and finally it fails with "Number of MapFailedExceptions: 1" 
and a huge (+7GB) log file I could not read.
I have manually split problematic tile to a half its original size and 
then both resulting tiles fail to compile. After dividing them /2, 3 
of the 4 tiles fail, but then mkgmap gives the following error:

Exception in thread "main" java.lang.NegativeArraySizeException
at 
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.(HGTConverter.java:85)

at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:76)
at 
uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:341)
at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:191)
at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:104)

at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:679)
at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)

at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
And log contains over 10⁷ lines like this: WARNING (HGTConverter): 
55129161.o5m: height interpolation returns void at 30.837045,2.094557

After 2 more /2 divisions I could build all tiles.
The smallest failing tile can be downloaded from 
http://alternativaslibres.org/tmp/55129083.o5m


[1] java -Xmx4500m -ea -Dlog.config=gging.properties -jar mkgmap.jar 
--block-size 48 --dem=hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=lygons/$pais.poly --dem-dists312,6624,9936,13248,26512 
--overview-dem-dist8000 --output-dir=./tmp --gmapi --show-profiles=1 
--bounds=unds.zip --precomp-sea=sea.zip --max-jobs --route --latin1 
--code-page52 --country-name=$PAIS --country-abbr=$ABR 
--area-name=APA --family-name="OSM $MAPA DEM" --family-id=5$FID 
--product-id=--product-version=$VERSION --series-name="OSM-$MAPA-DEM" 
--overview-mapname=BR-5$FID --overview-mapnumberU5${FID}000 
--name-tag-list=AMETAG --index --process-destination --process-exits 
--housenumbers --reduce-point-density=--polygon-size-limits="24:12, 
18:10, 16:0" --add-pois-to-areas --link-pois-to-ways 
--location-autofill=_in,nearest --drive-on�tect,$DRIVEON 
--check-roundabouts --check-roundabout-flares 
--license-file=cense_OSM_${HGT} --copyright-file=copyright $LANGUAGE 
--road-name-config=ONFIG 
--x-mdr7-del=ADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED 
--style=o --remove-ovm-work-files=true -c ${pais}-DEM.args





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

Re: [mkgmap-dev] Creating a map with contour lines and DEM

[Bernhard Hiller]

The solution was actually simple: the lines created by Srtm2Osm had a 
"contour" tag only, but no "contour_ext" tag.
It is necessary to supply the "-cat" option, together with values for 
major, medium, and minor elevation steps.

I.e. I changed the call to
Srtm2Osm.exe -step 25 -cat 500 100 25 -large
and now things work.

Am 13.02.2018 um 19:38 schrieb Bernhard Hiller:
I was trying to create a map of Taiwan including DEM data and 
elevation contour lines. The DEM part was easy. But strangely, I 
cannot get elevation contourlines.


I downloaded hgt data from Viewfinder Panoramas, and placed them into 
the cache directory of srtm2osm.

I called srtm2osm in a batch file:

SET SRTM=:\Program Files (x86)\OpenStreetMap\Srtm2Osm\Srtm2Osm.exe"
SET OUTPUTDIR=\Maps\Raw\Taiwan.DEM\

%SRTM% -bounds1 21.81 120 23.6 122.1 -o %OUTPUTDIR%TaiwanS.osm
%SRTM% -bounds1 23.59 120 25.4 122.1 -o %OUTPUTDIR%TaiwanN.osm

TaiwanS mearures 1554993 kB, TaiwanN 2249418 kB (I must do it in 2 
parts, otherwise the program uses more than 7 GB of RAM and causes 
lots of paging).
Next, I sorted one of the files with osmosis (originally I sorted and 
merged both of them, and then merged with an extract from Geofabrik; 
that's what I plan to do when I got things working...):


SET OSMOSIS=:\Program Files 
(x86)\OpenStreetMap\osmosis-0.46\bin\osmosis.bat"

SET INPUTDIR=\Maps\Raw\Taiwan.DEM\
%OSMOSIS% --read-xml %INPUTDIR%TaiwanS.osm --sort --write-pbf 
%INPUTDIR%Taiwan_Ele.osm.pbf


The output file measures 16670 kB.
Next, I split it with

SET JAVA=:\Program Files\Java\jre1.8.0_121\bin\java.exe"
SET SPLITTER=:\Program Files 
(x86)\OpenStreetMap\splitter-r590\splitter.jar"

SET INPUTDIR=\Maps\Raw\Taiwan.DEM\
SET INPUTDATA=iwan_Ele.osm.pbf
SET NAME=ernieMap Bike Taiwan"

%JAVA% -Xmx6G -jar  %SPLITTER% ^
%INPUTDIR%\%INPUTDATA% ^
--description=AME% ^
--max-nodes%0 ^
--no-trim ^
--mapidG120001 ^
--max-threads=^
--keep-complete=ue

which creates 3 pbf-files.
Finally, I build the map with

SET JAVA=:\Program Files\Java\jre1.8.0_121\bin\java.exe"
SET MKGMAP=:\Program Files (x86)\OpenStreetMap\mkgmap-r4107\mkgmap.jar"
SET 
PREPROC=\Data\Projects\Projects.Net2\StylePreProcessor\bin\Debug\StylePreProcessor.exe

SET STYLE=\Maps\Development\Style.Mapnik\Mapnik.Bike
SET DEMPATH=\Maps\Raw\Taiwan.DEM
SET NAME=ernieMap Bike Taiwan"
SET TYP=4712.TYP

%PREPROC% /in=\Maps\Development\Style.Mapnik\Mapnik.Base /out=%STYLE% 
/defines=KE,THAI

copy E:\Maps\Development\Style.Mapnik\%TYP% %TYP%
copy "C:\Program Files (x86)\OpenStreetMap\GMT\gmt.exe" gmt.exe
gmt.exe -wy 4712 %TYP%

%JAVA% -Xmx6G -ea -jar %MKGMAP% ^
--style-file=TYLE% ^
--family-name�rnieMapTaiwan ^
--family-id712 ^
--product-id=^
 --description=AME% ^
--series-name=AME% ^
--name-tag-list=me:en,int_name,name ^
--latin1 ^
--add-pois-to-areas ^
--route ^
--location-autofill=unds,nearest ^
--preserve-element-order ^
--draw-priority% ^
--index ^
--nsis ^
--show-profiles=^
 --generate-sea=ltipolygon,extend-sea-sectors,floodblocker ^
--max-jobs=^
--dem-poly=eas.poly ^
--x-dem=EMPATH% ^
 --x-dem-dists314,4000,6000,8000,1,15000,2,3 ^
--gmapsupp 4*.osm.pbf ^
%TYP%

move gmapsupp.img E:\Maps\Use\Taiwan.IMG

which creates an IMG file of 18798 kB.
It is recognized by my Oregon 600.
In the demo mode, I navigate to a waypoint (Luigui, 22.99573 N, 
120.63496 E).
I expect to see a map of contourlines only. But I get a completely 
white map.
Elevation from DEM is 250m directly adjacent to the waypoint, and 
other sensible values nearby.


The style file contains:
contour=evation & contour_ext=elevation_major & (ele > 0 | ele < 
0) { name '${ele|conv:m=t}'; } [0x20 level 4]
contour=evation & contour_ext=elevation_medium & (ele > 0 | ele < 
0){ name '${ele|conv:m=t}'; }   [0x21 level 2]
contour=evation & contour_ext=elevation_minor & (ele > 0 | ele < 
0) { name '${ele|conv:m=t}'; } [0x22 level 0]


The TYP file (created and compiled with MapTk) contains:
[Polyline]
Type=20
String=Höhenlinie
String=Elevation
Color=0x00
Line
[END]

[Polyline]
Type=21
String=Höhenlinie
String=Elevation
Linewidth=
Color=00x00
[END]

[Polyline]
Type=22
String=Höhenlinie
String=Elevation
Linewidth=
Color=00x00
[END]
which should cause black elevation contour lines.

What do I do wrong?

Thanks a lot for your hints.

Kind regards,
Bernhard



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

[mkgmap-dev] Creating a map with contour lines and DEM

[Bernhard Hiller]

I was trying to create a map of Taiwan including DEM data and elevation 
contour lines. The DEM part was easy. But strangely, I cannot get 
elevation contourlines.


I downloaded hgt data from Viewfinder Panoramas, and placed them into 
the cache directory of srtm2osm.

I called srtm2osm in a batch file:

SET SRTM="C:\Program Files (x86)\OpenStreetMap\Srtm2Osm\Srtm2Osm.exe"
SET OUTPUTDIR=E:\Maps\Raw\Taiwan.DEM\

%SRTM% -bounds1 21.81 120 23.6 122.1 -o %OUTPUTDIR%TaiwanS.osm
%SRTM% -bounds1 23.59 120 25.4 122.1 -o %OUTPUTDIR%TaiwanN.osm

TaiwanS mearures 1554993 kB, TaiwanN 2249418 kB (I must do it in 2 
parts, otherwise the program uses more than 7 GB of RAM and causes lots 
of paging).
Next, I sorted one of the files with osmosis (originally I sorted and 
merged both of them, and then merged with an extract from Geofabrik; 
that's what I plan to do when I got things working...):


SET OSMOSIS="C:\Program Files 
(x86)\OpenStreetMap\osmosis-0.46\bin\osmosis.bat"

SET INPUTDIR=E:\Maps\Raw\Taiwan.DEM\
%OSMOSIS% --read-xml %INPUTDIR%TaiwanS.osm --sort --write-pbf 
%INPUTDIR%Taiwan_Ele.osm.pbf


The output file measures 16670 kB.
Next, I split it with

SET JAVA="C:\Program Files\Java\jre1.8.0_121\bin\java.exe"
SET SPLITTER="C:\Program Files 
(x86)\OpenStreetMap\splitter-r590\splitter.jar"

SET INPUTDIR=E:\Maps\Raw\Taiwan.DEM\
SET INPUTDATA=Taiwan_Ele.osm.pbf
SET NAME="BernieMap Bike Taiwan"

%JAVA% -Xmx6G -jar  %SPLITTER% ^
%INPUTDIR%\%INPUTDATA% ^
--description=%NAME% ^
--max-nodes=250 ^
--no-trim ^
--mapid=47120001 ^
--max-threads=4 ^
--keep-complete=true

which creates 3 pbf-files.
Finally, I build the map with

SET JAVA="C:\Program Files\Java\jre1.8.0_121\bin\java.exe"
SET MKGMAP="C:\Program Files (x86)\OpenStreetMap\mkgmap-r4107\mkgmap.jar"
SET 
PREPROC=E:\Data\Projects\Projects.Net2\StylePreProcessor\bin\Debug\StylePreProcessor.exe

SET STYLE=E:\Maps\Development\Style.Mapnik\Mapnik.Bike
SET DEMPATH=E:\Maps\Raw\Taiwan.DEM
SET NAME="BernieMap Bike Taiwan"
SET TYP=M04712.TYP

%PREPROC% /in=E:\Maps\Development\Style.Mapnik\Mapnik.Base /out=%STYLE% 
/defines=BIKE,THAI

copy E:\Maps\Development\Style.Mapnik\%TYP% %TYP%
copy "C:\Program Files (x86)\OpenStreetMap\GMT\gmt.exe" gmt.exe
gmt.exe -wy 4712 %TYP%

%JAVA% -Xmx6G -ea -jar %MKGMAP% ^
--style-file=%STYLE% ^
--family-name=BernieMapTaiwan ^
--family-id=04712 ^
--product-id=1 ^
 --description=%NAME% ^
--series-name=%NAME% ^
--name-tag-list=name:en,int_name,name ^
--latin1 ^
--add-pois-to-areas ^
--route ^
--location-autofill=bounds,nearest ^
--preserve-element-order ^
--draw-priority=25 ^
--index ^
--nsis ^
--show-profiles=1 ^
 --generate-sea=multipolygon,extend-sea-sectors,floodblocker ^
--max-jobs=4 ^
--dem-poly=areas.poly ^
--x-dem=%DEMPATH% ^
 --x-dem-dists=3314,4000,6000,8000,1,15000,2,3 ^
--gmapsupp 4*.osm.pbf ^
%TYP%

move gmapsupp.img E:\Maps\Use\Taiwan.IMG

which creates an IMG file of 18798 kB.
It is recognized by my Oregon 600.
In the demo mode, I navigate to a waypoint (Luigui, 22.99573 N, 
120.63496 E).
I expect to see a map of contourlines only. But I get a completely white 
map.
Elevation from DEM is 250m directly adjacent to the waypoint, and other 
sensible values nearby.


The style file contains:
contour=elevation & contour_ext=elevation_major & (ele > 0 | ele < 
0) { name '${ele|conv:m=>ft}'; }   [0x20 level 4]
contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 
0){ name '${ele|conv:m=>ft}'; }   [0x21 level 2]
contour=elevation & contour_ext=elevation_minor & (ele > 0 | ele < 
0) { name '${ele|conv:m=>ft}'; }   [0x22 level 0]


The TYP file (created and compiled with MapTk) contains:
[Polyline]
Type=0x20
String=0,Höhenlinie
String=4,Elevation
Color=0,0x00
Line=00..00
[END]

[Polyline]
Type=0x21
String=0,Höhenlinie
String=4,Elevation
Linewidth=1
Color=0,0x00
[END]

[Polyline]
Type=0x22
String=0,Höhenlinie
String=4,Elevation
Linewidth=2
Color=0,0x00
[END]
which should cause black elevation contour lines.

What do I do wrong?

Thanks a lot for your hints.

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

Re: [mkgmap-dev] "shop=no"

[Bernhard Hiller]

Hi Gerd,

that's a good point. Let's take a look at the numbers:
vacant 10542
no 2732
disused 2389
abandoned 9
vacancy 9
Vacant 7
unused 5
none 4
disused:supermarket 2
Vacant Store 1
vacant;survey 1
vacat 1
computer;vacant 1
vacant;chemist 1
abandone 1
disused:shop=car 1
disused:bicycle 1
disused:clothes 1
disused:garden_centre 1
disued (backery) 1
disused:hairdresser 1
disused:pet,garden_centre 1
disused:butcher 1
disused:mall 1
disuded 1

I am not so sure what do with "vacant" as this might indicate a 
temporary state of that shop, but depending on the place it might never 
become a shop again.
Also with the "disused" cases, the shops could be in operation a short 
time later again, or never.
At least, these cases are more important (vacant) or equally important 
(disused) as shop=no.


By the way, I run an overpass query for shop=no in the Frankfurt/Germany 
region: the "shop=no" tags are typically used here at fuel stations... 
Same holds true for Berlin or Prague. In England, I stumbled upon node 
node https://www.openstreetmap.org/node/412490731 which combines shop=no 
with amenity=icecream. There are some rare occasions where a building 
was mapped with shops in all adjacent building which received a shop=no.


More input from other mappers / map makers is welcome.

Regards,
Bernhard

Am 18.08.2017 um 09:53 schrieb Gerd Petermann:

Hi Bernhard,

I've changed the default style in r3993, shortly after I learned about shop=cant
https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dvacant

Not sure if the default style should ignore this as well?

Gerd
____
Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Mittwoch, 16. August 2017 19:19:01
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] "shop="

In the forum, there is a discussion on the enormous variety of values
for some tags, see
https://forum.openstreetmap.org/viewtopic.php?idU541 (in Dutch).
There is also a link to a list showing the different values for the
"shop" tag:
http://mijndev.openstreetmap.nl/~marczoutendijk/taginfo-shop.html

You can see there that the combination "shop=" exists 2372 times,
"shop=ne" 4 times.

With our current default style, they'd be summed up by the line
   shop=[0x2e0c resolution 24]
which just would make them into a shop.

I guess we should better ignore the shop=/none combination (note: a
value containing "no" may still be correct), and provide a PoI based on
the other tags for that node.
What do you think?

Regards,
Bernhard
___
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] "shop=no"

[Bernhard Hiller]

In the forum, there is a discussion on the enormous variety of values 
for some tags, see 
https://forum.openstreetmap.org/viewtopic.php?id=55541 (in Dutch).
There is also a link to a list showing the different values for the 
"shop" tag: 
http://mijndev.openstreetmap.nl/~marczoutendijk/taginfo-shop.html


You can see there that the combination "shop=no" exists 2372 times, 
"shop=none" 4 times.


With our current default style, they'd be summed up by the line
 shop=* [0x2e0c resolution 24]
which just would make them into a shop.

I guess we should better ignore the shop=no/none combination (note: a 
value containing "no" may still be correct), and provide a PoI based on 
the other tags for that node.

What do you think?

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

Re: [mkgmap-dev] amenity=restaurant and search index

[Bernhard Hiller]

The index may be sometimes confusing: there are categories which sum up 
other categories, and that also depends on the device type.

See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
E.g. 0x2a04 is shown under
- All Categories
- Asian
- Chinese
on an Oregon 600, but the category "Asian" is missing on some other devices.

According to that site, "International" shows 0x2a06 only on most Garmin 
devices, but additionally 0x2a13-0x2a1f on Oregon 600.


The categories are hard-coded by Garmin (well, you can edit the language 
file and change their meaning), so they will show up on your device even 
if there is no POI available for that category.


Am 27.04.2017 um 13:18 schrieb Gerd Petermann:

Hi all,

I've postponed the problems regarding --lower-case and looked at other problems 
in the index.
I've noticed that some restaurants do not show up where expected.
I am not sure if this is caused by wrong data in the index or simply by style 
rules, probably both.
For example:
I have a small test file containing some amenity=staurant, but none has 
cuisine=international (0x2a06)  , still
the search menu shows an entry for that category but finds no entry.
On the other hand, many restaurants are found where not expected, for example 
in category pizza I find all 0x2a00

The default style contains rules to add POI with type  0x2a and it seems to 
work for many of them,
but at least these last two rules look suspicious:
amenity=staurant & cuisine=* [0x2a13 resolution 24]
amenity=staurant [0x2a00 resolution 24]
Why do we use two different types for these "mop up" rules?

Gerd




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

Re: [mkgmap-dev] RAM and mdr Europa ?

[Bernhard Hiller]

Hi Thomas,
since you have 10 GB of RAM for all of the tasks running on your 
computer, I doubt that 9800 MB for Java/mkgmap is actually feasable. 
With Win 7, I put away some 1200-1500 MB for the operating system.
If a process gets more memory, swapping to disk will occur, which is a 
slow process, and the garbage collection might fail in such situations 
(well, not sure for Java, but I saw such situations with .Net).
I do not know how much RAM will be used up by WIN 10, but I think 
replacing "/-Xmx9800m/" by "/-Xmx8500m/" could be worth a test; you 
could also (additionally) set the initial heap size to that amount 
("/-Xms8500m/") .

Bernhard

Am 24.03.2017 um 17:07 schrieb Thomas Morgenstern:


Hi, I have a W10, 64 bit machine  and 10 GB RAM. Since  a few months i 
can not generate the mdr-file for Europa from 
www.Download.Geofabrik.de In a first run i generate only all the 
maptiles. No Problem. in a second i will generate the overview, tdb 
and mdr. I start j/ava -Xmx9800m -XX:-UseGCOverheadLimit jar 
mkgmap.jar code-page=1252 -family-id=1901 -x-split-name-index -index 
D:\Karten\Europa\*.img./


and get the error.

with mkgmap-r3864 it get the same error.

How many RAM must i have for Europa complete ?. In august 2016 it was 
possible to create the mdr with 6 GB RAM. But the filesize is growm ...


thomas






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

Re: [mkgmap-dev] Performance with large files

[Bernhard Hiller]

Hi Gerd,

mkgmap is running now, I'll likely report tomorrow.

But I already saw that the first tile took very long, and in the areas 
file it is:

4311: 1765376,-935936 to 2822144,139264
#   : 37.880859,-20.083008 to 60.556641,2.988281

So, I suspect that here could be a problem: some of the newly added 
extracts inflates the area covered by the map extremely. I first thought 
of the Dutch Antilles in the Caribean, but that's farther west and 
farther south. I cannot see how that area comes into the map.


The maps I created before, typically contained Germany, Chechia, 
Austria, Liechtenstein, and Switzerland. That took normally less than an 
hour per map.


Now I added Luxemburg, Belgium and Netherlands also, which does not 
increase file size a lot. But the time for map creation was increased 
enormously.


Bernhard

Am 21.03.2017 um 09:17 schrieb Gerd Petermann:

Hi Bernhard,

other tests did not show new results. Any idea why you got so different numbers?

Gerd

Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 20. März 2017 07:40:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Performance with large files

Hi Bernhard,

reg. splitter:
If I got that right you used pbf as input format for the "Germany" result and *.o5m for 
"Central Europe".
Since the o5m format allows faster processing the splitter times are okay for 
me.

reg. mkgmap:
I've added a few lines in mkgmap to report the calculation time for each tile. 
As you might know,
mkgmap starts a few threads (depending on the max-jobs option) and each thread 
processes on tile at a time.
The threads share only a few data structures, and mkgmap doesn't collect much 
information for each tile in
memory, so  there is no good reason for an increase of run time per processed 
tile.

My system is probably close to yours, a machine with 8 GB Memory and a 4 core 
CPU (i5) running a 64 Windows.

The attached patch adds a few lines to report the calculation time for a tile. 
The patched version is here:
http://files.mkgmap.org.uk/download/339/mkgmap.jar

  I've used the patched version to compile a map with the OpenfietsMap Lite 
style of an area around (and including) Germany .
I used the attached dach-x.poly file with osmconvert and a planet.o5m file from 
2017-01-17.
and splitter with max-nodes0 & keep-complete=true and found what I 
expected.
Times are between 7 and 35 seconds per tile, most are around ~20 secs, no 
increase in time/tile.
The time for the creation of the index / gmapsupp is rather short compared to 
the overall run time.
The complete mkgmap log is here :
http://files.mkgmap.org.uk/download/340/mkgmap_2017-03-20-064126.log

So, I cannot reproduce your result for mkgmap.
Maybe your machine was busy with other work like installing updates, maybe some 
tiles in the added area
require much more time, maybe times depend on program options or style.

I just noticed that I did not enable assertions (-ea) so  I now try a variant 
with a max-nodes0 and -ea.

Gerd








____
Von: mkgmap-dev  im Auftrag von Bernhard 
Hiller 
Gesendet: Sonntag, 19. März 2017 19:46:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Performance with large files

Eventually I updated Java and tried the latest version of mkgmap 3847
(and also splitter 580).
The extracts were retrieved from Geofabrik on Saturday 18.
Germany: 2.93 GB
plus additional countries: 5.62 GB (incl. Germany) which were combined
to a 7.57 GB o5m file.
splitter: Germany 14 minutes - Central Europe 20 minutes
mkgmap: Germany 30 minutes - Central Europe 133 minutes
While splitter performed better than O(n) (more like O(sqrt(n))),
mkgmap performed worse than O(n^2).

Am 19.03.2017 um 12:06 schrieb Bernhard Hiller:

How is mkgmap expected to behave when input files grow in size? Is a
linear inrease in calculation time - i.e. O(n) - expected, or an
increase beyond linearity?
E.g. when I create a map with routable lines for bicycle, mkgmap takes
some 30 minutes for Germany alone (3 GB pbf file resulting in 850 MB
img file), but more than  2 hours for Germany and some neighboring
countries (7 GB o5m file, resulting 1.4 GB img).
Are there many calculations at O(n^2) or beyond in mkgmap, or is this
due to other factors, e.g. memory limitation?
Notes:
mkgmap is called by
%JAVA% -Xmx6800M -ea -jar %MKGMAP% 
on 64bit Win 7;
swapping to disc does not occur.
But I am more interested in a general rule than in some hints for
improving the performance in this concrete case. E.g. how I could
estimate the duration if I add some further countries...
Thanks for your hints.


___
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

Re: [mkgmap-dev] Performance with large files

[Bernhard Hiller]

Eventually I updated Java and tried the latest version of mkgmap 3847 
(and also splitter 580).

The extracts were retrieved from Geofabrik on Saturday 18.
Germany: 2.93 GB
plus additional countries: 5.62 GB (incl. Germany) which were combined 
to a 7.57 GB o5m file.

splitter: Germany 14 minutes - Central Europe 20 minutes
mkgmap: Germany 30 minutes - Central Europe 133 minutes
While splitter performed better than O(n) (more like O(sqrt(n))),
mkgmap performed worse than O(n^2).

Am 19.03.2017 um 12:06 schrieb Bernhard Hiller:
How is mkgmap expected to behave when input files grow in size? Is a 
linear inrease in calculation time - i.e. O(n) - expected, or an 
increase beyond linearity?
E.g. when I create a map with routable lines for bicycle, mkgmap takes 
some 30 minutes for Germany alone (3 GB pbf file resulting in 850 MB 
img file), but more than  2 hours for Germany and some neighboring 
countries (7 GB o5m file, resulting 1.4 GB img).
Are there many calculations at O(n^2) or beyond in mkgmap, or is this 
due to other factors, e.g. memory limitation?

Notes:
mkgmap is called by
%JAVA% -Xmx6800M -ea -jar %MKGMAP% 
on 64bit Win 7;
swapping to disc does not occur.
But I am more interested in a general rule than in some hints for 
improving the performance in this concrete case. E.g. how I could 
estimate the duration if I add some further countries...

Thanks for your hints.



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

[mkgmap-dev] Performance with large files

[Bernhard Hiller]

How is mkgmap expected to behave when input files grow in size? Is a 
linear inrease in calculation time - i.e. O(n) - expected, or an 
increase beyond linearity?
E.g. when I create a map with routable lines for bicycle, mkgmap takes 
some 30 minutes for Germany alone (3 GB pbf file resulting in 850 MB img 
file), but more than  2 hours for Germany and some neighboring countries 
(7 GB o5m file, resulting 1.4 GB img).
Are there many calculations at O(n^2) or beyond in mkgmap, or is this 
due to other factors, e.g. memory limitation?

Notes:
mkgmap is called by
%JAVA% -Xmx6800M -ea -jar %MKGMAP% 
on 64bit Win 7;
swapping to disc does not occur.
But I am more interested in a general rule than in some hints for 
improving the performance in this concrete case. E.g. how I could 
estimate the duration if I add some further countries...

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

[mkgmap-dev] Re-using a splitter result

[Bernhard Hiller]

From one data extract (comprising Germany, Austria, Switzerland, 
Czechia, Belgium, Netherlands), I create 3 maps:

- a routable map for car with id 4312
- a routable map for bicycle with id 4311
- a shared map with points of interest, areas, and some lines (river, 
railway, etc) with id 4310
Due to an "activity routing" capable firmware, the routable maps must be 
separated.
Currently, I call splitter 3 times, with those different ids, and 
different names. All other parameters for splitter stay unchanged. That 
process costs a lot of time.

Is there some way to use the result of splitter for all three maps?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] highway-symbol for maxspeed?

[Bernhard Hiller]

I was trying to show maxspeed information on the map.

In the lines file, I added
highway=* & maxspeed=* {addlabel '${maxspeed}'}
which replaced the name by maxspeed.

Next, I looked at some examples in the default style which add ref as a 
label (but whose syntax I do not understand - looks more like changing 
the value fo the name tag), and tried to adjust it for maxspeed:
highway=* & maxspeed=* { ${maxspeed|highway-symbol:hbox}; addlabel 
'${maxspeed}'}

fails with an error message.

Do I need to add the result to some variable? I tried
highway=* & maxspeed=* {set x='${maxspeed|highway-symbol:hbox}'; 
addlabel '${maxspeed}' ; }

no - that repalces name by maxspeed again.

Is it possible to add such markers as are used for reference numbers to 
the highways which show maxspeed instead of something else? If so, how 
can that be achieved?

Thanks a lot for your hints.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing Algorithm of Garmin

[Bernhard Hiller]

Cze´sć Andrzej,

thanks for this (bad) information. Looks like the Oregon 600 (an outdoor 
device) uses the newer algorithm.
Well, it means, I can now stop optimizing for the "correct" route, and 
perhaps rather try to "optimize" the calculated time for the selected 
route (i.e. get it closer to my driving times)...


Am 16.08.2014 14:46, schrieb Andrzej Popowski:

Hi Bernhard,

Garmin has 2 version of routing algorithm, older and newer. Older is 
used by Mapsource, older nuvi, probably by outdoor devices. Newer 
algorithm is used by BaseCamp and last 2-3 generations of nuvi.


Newer algorithm is designed for speed of calculation rather than 
quality of results. Finding fastest way is based on road classes. At 
longer distances device uses only class 4 roads ignoring shortcuts 
with lower class. That's why you can optimize route manually.


Older algorithm is more precise, it can use lower class roads, when 
class 4 roads are missing. Calculations are longer. But probably you 
still can find better route manually.




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

[mkgmap-dev] Routing Algorithm of Garmin

[Bernhard Hiller]

When selecting "Minimize Distance", the result conforms with the 
expectations: the shortest route is selected by the Garmin Oregon 600.


But with "Minimize Time", things are different. It is not at all the 
route with the shortest time.
By setting a "Via Point", I can have it calculating my preferred route, 
which is calculated with a shorter time. I.e. despite the title of my 
selection, the device did not minimize time.


Example: Travel from Bayreuth to Erlangen.
The Oregon calculates a long route via motorways, 98.4 km, at 67 minutes.
With a Via Point west of Ebermannstadt, the distance is shortened to 
64.9 km, but also the time is now 60 minutes only.
The longer distance might be appropriate - but I find the longer time 
strange. It is 7 minutes / 10% longer by time!


Travelling along my preferred route, the device has to recalculate 
several times, with some more such results.
E.g. from Obernsees, it prefers 86.4 km at 56 minutes over a route of 
51.8 km at 46 minutes - 10 minutes or 20% longer!


From east of Ebermannstadt, it prefers 39.8 km at 30 minutes over 29 km 
at 26 minutes.


All the preferred routes use long sections of motorways, and reduce the 
sections on roads with low road_class attribute(road_class=2; lower 
values are not present in my preferred route).


What are your experiences? How much is the "penalty" for low road_class 
values?

Are still other factors important?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap 3313 bug: POI names missing

[Bernhard Hiller]

Thanks, that did the trick.
That was a change to mkgmap which made it incompatible with older styles.
Strangely, the new map has 182 MB, 25 MB less than the old version.

Am 05.07.2014 11:31, schrieb Bernd Weigelt:

add something like this to end of 'points'. 'lines', 'polygons'

|
| # The finalizer section is executed for each element when a rule with an
| element type matches
|
| name=* { name '${name}' }


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

Re: [mkgmap-dev] How to remove an index from an existing map

[Bernhard Hiller]

Thanks a lot for your hints.

> --index is only about address search. POI search is independent of 
address search.

Thanks for that hint. I did not know that.

> it looks like it generates the "index" on the fly from the tile data.
With the slow speed of the items appearing in the list, that likely 
holds true for the Oregon series also.


> use 0x0 codes that are not searchable
Well, I could do so when creating my own map. But the situation is the 
other way round: I want the data of my map to be shown, but the data of 
other maps to be ignored (and these otgher maps use the "normal" codes).


Consequently, with the current firmware of the Oregon, it is not 
possible to de-activate the POI search of certain maps which are 
available on the device.

A disappointing result, but at least I learned some things...
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to remove an index from an existing map

[Bernhard Hiller]

Czesc Andrzej,

thanks for your hints. Unfortunately, it did not work.

Next, I downloaded a fresh extract from Geofabrik and created a fresh 
map without an index. I verified that the maps which come with the 
device do not have POIs (well, there are some: all of them are military 
or civil airports, but that's it). After copying the map into the 
device, all the POIs were present.


That means, the device reads the POIs from the tiles (?) or somewhere 
else from the map when no index is present.


I tried to add an empty index by creating osmmap.mdx and osmmap_mdr.img 
files from a small JOSM download, and then created the gmapsupp with the 
"normal" tiles and that index - that did not work.


An Oregon does not have an option to select the map for search (even not 
enabled maps are used!), despite its rather high price it seems not to 
be a "better" device...


Other ideas?

Kind regards,
Bernhard

Am 02.07.2014 22:43, schrieb Andrzej Popowski:

Hi Bernhard,

On PC index is a file with name *_mdr.img, you can remove this file 
form registry (probably together with  *.mdx).


In a gmapsupp.img index is a subfile with name *.mdr. You can split 
img to subfiles, delete *.mdr and then merge subfiles back.


Better Garmin devices have option to select map for search, maybe 
Oregon too? Is there any "menu" button at POI search windows?




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

[mkgmap-dev] How to remove an index from an existing map

[Bernhard Hiller]

Whenever more than one map exists on an Oregon, the indices of all those 
maps are used for POI search reagrdless if the maps are "enabled" or not.


When the areas of maps do overlap, several POIs are listed twice (or 
even more often depending on the number of maps).
Since I use some POI codes differently from the standard (combined with 
my own "language pack"), this leads to even more confusion.


Hence I'd like to know if - and how - and index can be removed from an 
existing map.
In case that the gmapsupp.img file is created from precompiled tiles 
(e.g. VeloMap), is it possible to change the commandline such that the 
gmapsupp won't contain an index (no, just omitting the --index option 
does not do the trick, despite a file size of 330 MB vs. 337 MB fro 
Bavaria)?

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

[mkgmap-dev] Routing speeds on Oregon 600/400

[Bernhard Hiller]

Chapter 4.6.5 of the style manual shwos a table with road speeds and its 
corresponding "highest speeds".
I created a small test map with roads of ca. 100 km length of all 5 
road_types and added speed limits which translate into the 8 different 
road_speed codes with the current (v3310) default style.


Following table shows my car navigation results on an Oregon 600 with 
current firmware (3.90):

Roadspeed   DistanceTimeSpeed   Simulationspeed
7   99,900:53:27112,14  254
6   99,700:56:41105,53  130
5   100 01:00   100,00  100
4   99,501:16   78,55   90
3   100 01:34   63,83   70
2   99,902:03   48,73   50
1   99,603:06   32,13   30
0   100 06:09   16,26   16

The "Speed" is calculated by dividing the distance to destination by the 
time to destination;
the "Simulationspeed" is the speed shown on the device when you select 
the simulation option.

The speeds do not depend on the road_type value.
The speeds for classes 0, 1, 2, 3, and 7 are multiples of 10mph.
When using a different routing type (e.g. pedestrian), the simulation 
speed did not change (i.e. a pedestrian "walking" at 50 km/h...), but 
the calculated time to destination changed (i.e. a pedestrian was doing 
ca 5 km/h, a cyclist ca. 25 km/h).


With an Oregon 400 with old firmware (4.20), values are slightly different:
Roadspeed   DistanceTimeSpeed   Simulationspeed
7   99,900:45:20132,22  129
6   99,700:51:51115,37  113
5   100 00:56   105,63  103
4   99,501:07   89,10   87
3   100 01:32   65,22   64
2   99,902:03   48,73   48
1   99,503:06   32,10   32
0   100 10:16   9,749

The main difference is in faster speed for higher road_speed types, but 
lower simulation speed.


This means that Garmin uses different speeds for calculating the time to 
destination between different device types!


I hope this information helps the creators of maps, and helps to clarify 
questions on why this route was taken instead of that...
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] POI index issues

[Bernhard Hiller]

Hi Brett,

an issue with the index on a Garmin device is that it requires specific 
codes for specific items. For a comparison of Garmin models and the 
use/appearance of codes, see 
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types - In most 
cases, the meaning is the same for different models.


In your command, you use
--style-file=styles\mapnik\ ^
i.e. a relative path to the style, and a final backslash. Are you sure 
that the "correct" style was used (e.g. when you inspect your map with 
QLandkarte)? I use absolute path, without a final backslash, but that 
might be irrelevant.


It is also my impression that Garmin uses all maps (even those which 
were switched off) when a POI search is performed - try to remove them 
as much as possible (I change the extension from *.IMG to *.IM) - I 
haven't tried that with the base map yet...


Regards,
Bernhard

Am 24.11.2013 00:51, schrieb Brett Russell:

Hi

Time to follow up on this issue from some time back as I have not 
found any solutions.  It would be good to have the index search 
feature refined.   Anyway here is it again.   Thanks for your 
consideration.


I have loaded my latest img made using 2800 of mkgmap and a custom 
style along with typ file on to a Garmin Rino 650.  This unit has only 
ever had the OSM maps that I have created on it.  The POI lookup has 
been causing me a few issues in the past with my 62S being much better 
but that might be due to it having Garmin's own Topo map loaded.  I am 
at a loss how and what index from what img file my Garmins use.


Anyway, the problem is nothing comes up when I select all POI so I 
went into geographical features and then water features to find a 
lake.  No water features showed up.  I then selected land features and 
then could find the lake that I was after.  It appears that at least 
on the Rino 650 the POI index has issues.


It the above a known problem with mkgmap or is their something wrong 
with my style and/or typ file?  I use the following bat in Windows 7 
to create the img.


REM mkgmap command line
REM ---
java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^
 --max-jobs ^
 --gmapsupp ^
 --route --drive-on-left --check-roundabouts ^
 --generate-sea ^
 --remove-ovm-work-files ^
 --add-pois-to-areas ^
 --location-autofill=nearest ^
 --index ^
 --style-file=styles\mapnik\ ^
 --description="Ent_World 20M Contours" ^
 --country-name=Australia --country-abbr=AU --region-name=Tasmania 
--region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^
 --family-name=contours --draw-priority=31 --transparent 
Ent_contours_20M\Ent_world*.osm.pbf ^

 styles\mapnik\mapnik_play.typ

Cheers

Brett


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

Re: [mkgmap-dev] Address index for multi-country map

[Bernhard Hiller]

Thanks for your hints. With the precompiled boundaries, the map of the 
European countries receives a functional address index. When creating a 
map of South-East Asia (Thailand, Malysia, Singapore, Cambodia, Vietnam, 
Indonesia, Laos), the address index does not work: no roads are found in 
Bangkok or Kuala Lumpur!


Beyond the fact of the defectiveness with South East Asia, that 
procedure does not feel correct at all: it means that I have to get the 
same (?) data from two different locations in two different formats. Or 
even three, when using the --precompiled-sea option (which I never got 
working with South East Asia).
All those files have different update schedules which means 
inconsistencies. With central Europe, those inconsistencies are not very 
likely, since borders and coast lines are available with high quality. 
That does not apply to South East Asia. Last week I updated some 
sections of the Thai-Malaysian border, and today of the South-Thai coast.


I know that sometimes a correct solution may be very difficult, and wtf, 
let's take a shortcut with a "pragmatic" solution. How complicated is a 
"correct" solution here?

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

Re: [mkgmap-dev] Address index for multi-country map

[Bernhard Hiller]

Meanwhile I did some experiments.

With a fresh download from Geofabrik, I started with germany.osm.pbf 
without any additional modification by osmconvert. I split it, and 
created the map with the same parameters and style file.

With the examples from Germany, I received the same results.

Next, I removed the "include" sections from the style files and replaced 
them by the contents of the respective files.

Same result.

Next, I tried the default style (as of mkgmap 2724). Again, the same 
results.


This means: it is not caused by a defect in my style file, nor in a 
defect in processing with osmconvert. Also a defect in resolving the 
include files can be excluded.

Still, the data downloaded from Geofabrik could be defective.

When I use the --country-name=Deutschland  --country-abbr=DEU 
parameters, places are correctly found in Germany. The country "Country" 
is no more available. For small villages, the index is then OK. But for 
towns consisting of some quarters, it is still defective: there are no 
roads neither in Erlangen nor in Bayreuth, and the "Geseeser Weg" can 
only be found in "Altstadt" instead of Bayreuth.


Next, I returned to mkgmap version 2654. I had to remove all lines with 
"admin_level" from relations, "capital" from points, the comparison of 
two values from lines. Also this did not solve the problem.


That means, that the creation of the address index is broken somewhere 
in mkgmap.


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

Re: [mkgmap-dev] One node - two index entries?

[Bernhard Hiller]

Thanks for your hint. Really a bad typo. And after correcting the typo, 
it works.


It is correct that Garmin places some points into two or more 
categories/sub-categories by itself. But that does not happen with 
hotel+restaurant.


2f16 is in Auto Services - Truck Stop and in Fuel Services - Truck Stop,
2e06 is in Shopping - Convenience and in Fuel Services - Convenience.
Note that each of them has only one Garmin ID.

The example from the style file will place any amenity=fuel with 
HGV_diesel=yes in both Truck Stop sub-categories, but not in a 
Convenience sub-categrory even if that is also available.


Also for the hotel+restaurant, two IDs are required, one in Lodging, and 
one in Food and Drink.


Am 09.11.2013 14:42, schrieb Marko Mäkelä:

On Sat, Nov 09, 2013 at 02:36:58PM +0100, Bernhard Hiller wrote:
Hence my question is: is it possible to get one node into the index 
twice in different categories?


FWIW, the Garmin Edge 705 does this for some POI types by itself. For 
example, a "Truck stop" or "Convenience store" will show up in 2 
menus.  These are in the default style:


amenity=fuel & fuel:HGV_diesel=yes [ 0x2f16 resolution 23]
amenity=fuel & shop=convenience [ 0x2e06 resolution 24]


I tried following rules:

tourism=hotel & amenty!=* [...]
tourism=hotel & amenty=* [...]


If you misspelled the amenity, then it obviously cannot work, unless 
you also misspell it in the data. :)


I do not see why it should not work (generate 2 Garmin POIs), but I 
have not used 'continue' much.


Best regards,

Marko



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

[mkgmap-dev] One node - two index entries?

[Bernhard Hiller]

Background:
Often hotels have a restaurant also, the combination of 
amenity=restaurant and tourism=hotel on one node (or area) is quite 
common. Now the hotel should be in "Lodging - Hotel", and the restaurant 
somewhere in "Food and Drink".
Hence my question is: is it possible to get one node into the index 
twice in different categories?


I tried following rules:

tourism=hotel & amenty!=* { name 
'${name|def:}(${stars}*)${operator|def:}' | '${name} ${operator}' | 
'${name}' | '${operator}' } [0x2b01 level 2]
tourism=hotel & amenty=* { name 
'${name|def:}(${stars}*)${operator|def:}' | '${name} ${operator}' | 
'${name}' | '${operator}' } [0x2b01 level 2 continue]

...
amenity=restaurant [0x2a00 level 0]

On my Oregon 600, only the hotel is indexed, but not the restaurant.

Is that currently possible with some different rules / order of rules, 
or not yet possible, or even not possible at all?

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

[mkgmap-dev] Address index for multi-country map

[Bernhard Hiller]

I try to build a map of Germany, Switzerland, Austria and Czech Republic 
with a functional address index.
I downloaded the Geofabrik extracts for those countries, combined them 
(after conversion to o5m format) with osmconvert, split them, and create 
the map.


The result is quite mixed: some places show up below "Country" instead 
of Germany, e.g.

- Addresses
- Spell Country: Country
- Spell City: Krummennaab
- Enter Street Name: (stopped here, works)
whilst
- Addresses
- Spell Country: Deutschland
- Spell City: Krummennaab
- No Results found

Some places show up below "Deutschland", but (almost) no road is available:
- Addresses
- Spell Country: Deutschland
- Spell City: Erlangen
- Enter Street Name: (blank)
- only "Buckenhofer Weg" available of a town with more than 10 
inhabitants...

whilst
- Addresses
- Spell Country: Country
- Spell City: Erlangen
- Enter Street Name: (blank)
- lists many roads of the town

Near my home in Bayreuth is "Geseeser Weg". I choose that example 
because that street name does not exist so often.

- Addresses
- Spell Country: Country
- Spell City: (Search All)
- Enter Street Name: Geseeser
- No Results found
but
- Addresses
- Spell Country: Deutschland
- Spell City: (Search All)
- Enter Strret Name: Geseeser
- lists "Geseeser Straße" and "Geseeser Weg" - select the latter
- Enter House Number: 1
- lists "Geseeser Weg Altstadt Deutschland" and "Geseeser Weg 
Schnörleinsmühle". Since the part of Bayreuth is "Altstadt" (but no one 
would write that down as part of the address - it is Geseeser Weg 1, 
95447 Bayreuth) select that

- shows correctly on the map

Let's try an example in Czeck Republic: Dukelská Ulica in Sokolov
- Addresses
- Spell Country: Ceská Republica
- Spell City: Sokolov
- No Results found
but
- Addresses
- Spell Country: Country
- Spell City: Sokolov
- Enter Street name: Dukelská
- Enter House Number: 1
- shows correctly on the map

I know that I can use command line parameters for mkgmap:
--country-name=Deutschland ^
--country-abbr=DEU ^
but that's not approriate here: there are 4 different countries to deal 
with. Otherwise, the parameters do their job correctly.


According to the documentation, the style file should help mkgmap 
determine the country, and both my lines and points files say on their top:

include 'inc/address';

How to solve this problem? Thanks for your hints.


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

Re: [mkgmap-dev] Numerical comparison of two tags

[Bernhard Hiller]

Steve,
thanks for the patch. I've just re-created the test map, and it works!
When will that patch be included in future releases?
Regards,
Bernhard
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Numerical comparison of two tags

[Bernhard Hiller]

I'd like to set maxspeed to the minimum of maxspeed, maxspeed:forward, 
and maxspeed:backward.

In my lines file, I use:

|maxspeed:forward=*&  maxspeed!=* { set maxspeed='${maxspeed:forward}' }
maxspeed:forward=*&  (maxspeed:forwardThat works only if exactly one tag is set. But when both forward and 
backward are available, I get the value of forward even if backward is 
less. An example is wayhttp://www.openstreetmap.org/browse/way/70594951.


I played with additional / different rules, and my conclusion is that it 
is NOT POSSIBLE to compare the values of two tags with each other.


For example, I tried:

|highway=*&  maxspeed!=* { set maxspeed=999 }
maxspeed:forward=*&  (maxspeed:forwardAnd you can guess the result: maxspeed=999, for that way with 
maxspeed:forward=60 and maxspeed:backward=40.


Is my conclusion correct?
And, if so, will there be a patch?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Provincial capitals

[Bernhard Hiller]

In case someone else is interested in the solution:
in the relations file, I added:

boundary=administrative & admin_level=* {
 apply role=admin_centre { set is_province_capital='${admin_level}'; }
}

And then in the points file:
...
place=city & population > 19 & cityxx!=yes {set cityxx=yes} [0x0500 
level 4 continue with_actions ]
place=* & is_province_capital<5 & cityxx!=yes {set cityxx=yes} [0x0500 
level 4 continue with_actions ]
place=city & population >  9 & cityxx!=yes {set cityxx=yes} [0x0600 
level 3 continue with_actions ]
place=* & is_province_capital<6 & cityxx!=yes {set cityxx=yes} [0x0600 
level 3 continue with_actions ]
place=city & population >  4 & cityxx!=yes {set cityxx=yes} [0x0700 
level 3 continue with_actions ]
place=* & is_province_capital=* & cityxx!=yes {set cityxx=yes} [0x0700 
level 4 continue with_actions ]
place=city & population >    & cityxx!=yes {set cityxx=yes} [0x0800 
level 3 continue with_actions ]
...

Am 29.09.2013 10:53, schrieb Bernhard Hiller:
> How can provincial capitals be detected by a style rule? I want to 
> show them at low zoom level, even if their population is rather little.
>
> Example:
> Phangnga town (South Thailand) has a population of some 10,000 people, 
> but it is the capital of Phangnga province (see 
> http://www.openstreetmap.org/browse/node/984029824). There is a 
> relation for the province boundary: 
> http://www.openstreetmap.org/browse/relation/1908799 which has 
> Phangnga set as its admin_centre; admin_level = 4.
>
> I tried in the points file:
>
> place=* & mkgmap:admin_level4=* & cityxx!=yes {set cityxx=yes} [0x0100 
> level 6 continue with_actions ]
>
> but that does not help: Phangnga city is shown at a high zoom level 
> only, instead of at the same zoom level with Bangkok (ok, that's not 
> useful, I do so temporarily to find out how things work).
> I tried place=city or place=village instead of place=*, same result.
>
> Only
>
> place=* & is_capital=province & cityxx!=yes {set cityxx=yes} [0x0100 
> level 6 continue with_actions ]
>
> works as expected. Fortunately, a mapper added the is_capital tag to 
> all Thai province capitals just a few days ago...
>
> But I think using the relation is a better option. Only: how can I do 
> that?
>
> Tried that with:
> mkgmap 2724, Java 7 u40 (64bit), Windows 7 (64bit)
>
> Thanks for your hints.
>

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

[mkgmap-dev] Provincial capitals

[Bernhard Hiller]

How can provincial capitals be detected by a style rule? I want to show 
them at low zoom level, even if their population is rather little.

Example:
Phangnga town (South Thailand) has a population of some 10,000 people, 
but it is the capital of Phangnga province (see 
http://www.openstreetmap.org/browse/node/984029824). There is a relation 
for the province boundary: 
http://www.openstreetmap.org/browse/relation/1908799 which has Phangnga 
set as its admin_centre; admin_level = 4.

I tried in the points file:

place=* & mkgmap:admin_level4=* & cityxx!=yes {set cityxx=yes} [0x0100 
level 6 continue with_actions ]

but that does not help: Phangnga city is shown at a high zoom level 
only, instead of at the same zoom level with Bangkok (ok, that's not 
useful, I do so temporarily to find out how things work).
I tried place=city or place=village instead of place=*, same result.

Only

place=* & is_capital=province & cityxx!=yes {set cityxx=yes} [0x0100 
level 6 continue with_actions ]

works as expected. Fortunately, a mapper added the is_capital tag to all 
Thai province capitals just a few days ago...

But I think using the relation is a better option. Only: how can I do that?

Tried that with:
mkgmap 2724, Java 7 u40 (64bit), Windows 7 (64bit)

Thanks for your hints.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Check style AND type

[Bernhard Hiller]

Thanks for the hint. The tools can at least do this one step, though the 
number format shown is a little confusing.
But it cannot check for items in the TYP file which are not used in the 
style.
And it cannot show the definitions in style file vs. TYP file, i.e. 
embassy and prison may stay mixed up.

My impression is that the community does not take this seriously yet.

Am 30.08.2013 13:49, schrieb nwillink:
> The latest typwiz3 includes a tool to check if polygon,line and poi types are
> not found in a TYP file associated with the img(s)
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Check style AND type

[Bernhard Hiller]

Is there a possibility to check a style together with the corresponding 
type file?
For example, a type could contain a line/poi/area which is not used at 
all in the style.
The other way round may be less important due to Garmin's default style, 
I think it should be possible to check that too.
But most important is consistency: yesterday I stumbled upon a 
combination with POI 0x3007 being an embassy in the style file, and a 
prison in the type file.
How can we easily detect such problems?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap and "memory-full-error"

[Bernhard Hiller]

Hi Christian,

I experienced the memory full error on my Oregon 400t some time ago. It 
seems that it was caused by a broken map, since never did it occur again 
after replacing that one map with a newer version.

Kind regards,
Bernhard
Am 29.05.2013 23:17, schrieb Christian H. Bruhn:
> Hi!
>
> I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this
> was the last firmware without the activity routing. With the activity
> routing the routing of my maps was broken (car routing over steps and
> ignoring of "access=").
>
> With the firmware 5.50 the routing was correct again. But after a few
> weeks I get the famous memory-full-error. Now I read that in the past
> several people reported this error with maps made with mkgmap.
>
> The only advice I found, was to use an recent firmware.
>
> Is there a known bug in mkgmap? How can I avoid the error?
>
> Christian
>
>

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

[mkgmap-dev] Bug-Report: java.lang.UnsupportedOperationException

[Bernhard Hiller]

After upating from version 2337 to 2484, I receive following error:

java.lang.UnsupportedOperationException
 at 
uk.me.parabola.mkgmap.osmstyle.eval.AbstractOp.value(AbstractOp.java:110)
 at uk.me.parabola.mkgmap.osmstyle.eval.EqualsOp.eval(EqualsOp.java:44)
 at uk.me.parabola.mkgmap.osmstyle.eval.OrOp.eval(OrOp.java:33)
 at uk.me.parabola.mkgmap.osmstyle.eval.AndOp.eval(AndOp.java:34)
 at 
uk.me.parabola.mkgmap.osmstyle.ActionRule.resolveType(ActionRule.java:59)
 at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:68)
 at 
uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay(StyledConverter.java:216)
 at 
uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:237)
 at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:75)
 at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144)
 at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
 at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:201)
 at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:198)
 at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
 at java.util.concurrent.FutureTask.run(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
Exiting - if you want to carry on regardless, use the --keep-going option

Then mkgmap stops.

Does it mean that current mkgmap does not like a statement in my style 
file? If so, how can I find out which one?

No, I did not change anything in that stylefile during the upgrade. 
mkgmap 2337 still exists on my machine, and I can switch back to that 
version with ease, and that works without the error.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] _link roads speed limit needs increasing

[Bernhard Hiller]

The ramps connect a secondary to a trunk. Hence, I'd tag them as 
trunk_link, not secondary_link. That could result in correct routing. 
But in the Bing images, the "dirt track" looks more like a residential, 
which could contribute a
contrary effect.
Since the ramps are very long in that special case, setting a speed 
limit explicitly might also help.
Maybe the Garmin device did not reognize that U-turn correctly, or the 
"penalty" for a U-turn is to small. Which tags are required that a 
U-turn is recognized as a U-turn?
Kind regards,
Bernhard
Am 03.08.2012 02:12, schrieb Peter Hendricks:
> Travelling down highway 32, then 329 in Thailand recently I was told to
> do a U-turn, then use a dirt track, rather than the ramp that linked to
> h'way 329. Try routing yourself in Mapsource or Basecamp at N14 27.106
> E100 32.322. It should look like something in this pic:
> https://dl.dropbox.com/u/30711166/OSM.T.jct.32-329-route.prob.jpg
>
> The route chosen by both GPSr&  Mapsource is actually longer than simply
> following the ramp, but it avoids the ramps.
>
> The ramps were drawn as secondary_link which in the Garmin map becomes
> low-speed ramp with speedlimit 20 and RC=2.
>
> The U-turn is a trunk_link =>  principal h'way, SL=90, RC=4.
>
> The dirt track has SL=20, RC=0.
>
> It looks like the Route Class is less important here than the SL: by
> following the main route you only travel for a short distance over a
> slow road (the track), whereas the ramps are quite long. Mathematically
> this would make for a quicker trip.
>
> To avoid people being routed off main highways I propose that ramps
> mapped from secondary_link get the same SL as secondary and that the
> speed limits on the other links are reviewed.
>
> Regards,
> Peter.
>
>

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

[mkgmap-dev] --generate-sea: no coastline shown

[Bernhard Hiller]

Due to problems with "--generate-sea" (for some - but not all - areas, 
no sea is drawn at all), I included "natural=coastline [0x15 resolution 
10]" in my style. But the coastline never was visible on the map. Only 
after removing the "--generate-sea"option, the coastline shows up. Can 
that be fixed?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Style rule for dual carriageways

[Bernhard Hiller]

I tried to make a map with an extra style for dual carriageways for each 
of highway=primary, secondary, and tertiary. The problem is that I do 
not see an appropriate tag to search for. Dual carriageways are 
characterized by two roughly parallel ways with oneway=yes. It is not 
necessary that they are tagged with highway=trunk.
highway=tertiary & oneway=yes  {set highway=tertiary_dual;}
often does the trick, but it changes also some other roads.
Do you have some better suggestions?

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