Re: [mkgmap-dev] Error when not using dem-poly

t files. > This seems to manage memory very well for our purpose, at least with Oracles > JRE. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de&

Re: [mkgmap-dev] Error when not using dem-poly

Hi Gerd, one general question: Do you see any advantage in using 'rounded' binary values or doesn't it matter at all? Henning On 08.01.2018 18:21, Gerd Petermann wrote: > Hi Nick, > > thanks for reporting. I'll try to reproduce the problem. Please note that > overview-dem-dist=88 > is

Re: [mkgmap-dev] Performance with zipped hgt files

data twice. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Montag, 8. Januar 2018 12:52:05 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, how about using a compressed temp-format for DEM information, which is more suitable for DEM-calculation? Or even store DEM-information in temp folder /DEM and just reuse them next time if possible. I think (at least for me) they don't change that often. So this will have a high impact

Re: [mkgmap-dev] Error when not using dem-poly

es. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Montag, 8. Januar 2018 12:56:18 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-de

Re: [mkgmap-dev] splitter r585 implements new option align-for-dem

Sorry, I forgotten to add this: It seems the reason is that --polygon-desc-file is not working well any more. So main reason is, that the map is getting bigger. You can see it in last mails attached kml-files. Henning On 18.01.2018 22:33, Henning Scholland wrote: > Hi Gerd, > I have qui

Re: [mkgmap-dev] splitter r585 implements new option align-for-dem

Hi Gerd I imported both kml-files to josm and added some taggs to make it more clear. landuse=grass -> split result based on r584 and also roughly same as polygon used by splitter landuse=industrial -> result with r585 and alignment to DEM. These tiles should be in templates args landuse

Re: [mkgmap-dev] splitter r585 implements new option align-for-dem

Hi Gerd I imported both kml-files to josm and added some taggs to make it more clear. landuse=grass -> split result based on r584 and also roughly same as polygon used by splitter landuse=industrial -> result with r585 and alignment to DEM. These tiles should be in templates args landuse

Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map

Hi Gerd, seems to work for me, but I also don't know what I should expect to see. In BaseCamp/MapSource the map is still in rectangle shape with light yellow coloured back ground in the area without data. Only difference is, that there is no more mouse over, indicating the mouse is in

Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map

With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] DEM: performance with bicubic interpolation

Hi Andrzej, I also suggest to make interpolation optional. So far I don't understand your argument. I agree, compilation time is not the only criteria. The question is, what is the benefit for the user. For example: If accuracy of srtm is +- 10m and the difference between with/without

Re: [mkgmap-dev] DEM: performance with bicubic interpolation

://en.wikipedia.org/wiki/Shuttle_Radar_Topography_Mission#Void-filled_SRTM_datasets Henning * * On 23.01.2018 20:59, Henning Scholland wrote: > Hi Andrzej, > > I also suggest to make interpolation optional. > > So far I don't understand your argument. I agree, compilation time is > not

Re: [mkgmap-dev] HGT - getElevation()

Hi Gerd On 15.01.2018 15:05, Gerd Petermann wrote: > Wouldn't it be better to change splitter so that it aligns tiles to HGT > raster? As long as we have rectangle map tiles, it would be a possible solution. But in future we might have non-rectangle tiles or even tiles, not splitted by

Re: [mkgmap-dev] How to handle missing hgt files or files with voids?

Hi Gerd, regarding 1) I can create a list of existing tiles of Viewfinder (which covers all land area so far I see). But it will be a long list. I remember it's about 25000 files in total. So maybe it's easier to create a polygon or at least take the list and let software create the polygon.

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Hi Gerd, I think this would be best and additionally I would suggest to make the polygon defined by user (as suggested in DEM-poly and precomp-sea thread). As default I would limit overview map to the map tiles. Maybe then we should name the parameter --overview-map-polygon=filename I'm not

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

ssume that this looks strange when you zoom in/out. > > I don't understand what you mean with maximizing/minimizing the polygon. > Please explain. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im A

Re: [mkgmap-dev] How to handle missing hgt files or files with voids?

some of those files have voids and that better data > exists (assuming that files without voids have fewer errors) > So, I think it would be good to have a list of those files that have voids. > > I'll see what is needed for this. > > Gerd > > __

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Hi Andrzej For Africa it can be useful, as areas with drive on left /right are at least roughly horizontal and vertical. Also you don't need overlapping for this use case. In general I also think, as soon as mkgmap can support non-rectangle tiles, it will be better obsolete. Using non-rectangle

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Oh, forgotten to mention: --polygon-desc-file=filename.osm you need to use for splitter. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Something similar is already possible with splitter. You can create an *.osm file with many polygons inside, each with tags name=* and mapid=* (see attachment). splitter will give you tiles with 6234 and per polygon a .args with list of necessary data tiles per map. That args-file you can hand

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Small tiles are mainly caused by not well aligned polygons. I attached you kmz with my splitter result. You can compare them for example in josm. I just have realized the small tiles while testing in beginning of DEM-support. While checking for broken img-files with 0kb I found several others with

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

On 13.01.2018 00:43, Andrzej Popowski wrote: > Is it this right-angled shape of polys required? I'm not 100% sure, but somehow I remember Gerd told me it needs to be rectangle shaped. Hening ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Style Manual

Hi Gerd, regarding tagisincomplete I would suggest to get rid of it. I can't imagine any use of it. For 2nd tagg it seems to be somehow useful. Maybe document it like ' Don't use in relation-style, is set to indicate line/poygon is part of MP-relation'. The usage in relation-styles should be

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi Gerd, first I would suggest to wait for Steve is merging the block size branch and just afterwards merge DEM branch to trunk. I think it's causing trouble merging DEM branch before, as user might end up with errors. Later start another branch for DEM-optimization. I don't know how other

Re: [mkgmap-dev] max-jobs patch

Hi Gerd, I think it's even more in combination with DEM. I usually use 6 of my 8 cores and ending up with 10 to 12 GB of heap. So I definitely agree with you available heap somehow needs to be considered as well. Not only CPU cores. Btw. for CFD/FEM analysis the simulation is usually is faster if

Re: [mkgmap-dev] patch for crash in MapSource

Same for me, but just did quick test. Will try on the weekend more detailed Henning On 8 Feb 2018, 16:57, at 16:57, lig fietser wrote: >Hi Gerd, > >I tested your patch but I still see frequent crashes near tile borders. > > > >Van:

Re: [mkgmap-dev] max-jobs patch

Hi Gerd, Maybe my map is somehow special, but mkgmap definitely need more than 1gb heap per job. I will check on the weekend. Can you please post a patched mkgmap.jar? How about doing it the other way round and suggest the user to use max-job option if mkgmap think it is useful? Henning On 8

Re: [mkgmap-dev] patch for crash in MapSource

- in front of the dem-options, am I right? On 08.02.2018 16:59, Henning Scholland wrote: > Same for me, but just did quick test. Will try on the weekend more > detailed > Henning > On 8 Feb 2018, at 16:57, lig fietser <ligfiet...@hotmail.com > <mailto:ligfiet...@hotmail.com>

Re: [mkgmap-dev] max-jobs patch

Hi Gerd, Hi Mike, I gave it a try on all my maps (splitted with max-nodes=1.600.000). Removed xmx and max jobs. mkgmap used all 8 logical cores and about 4GB of memory. So it seems, Gerd was correct with the 500mb per job. So I would suggest to limit max-jobs with 32bit java to 3 jobs and to

Re: [mkgmap-dev] max-jobs patch

Hi Gerd, maybe splitter can be modified  similar. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] max-jobs patch

; to reduce > IO caching effects. You should also not use --index, --gmapi or --gmapsupp > for these tests. > > Gerd > > > > Von: Henning Scholland <o...@hscholland.de> > Gesendet: Samstag, 10. Februar 2018 07:23 > An: Gerd

Re: [mkgmap-dev] Please test r4116

Well done Gerd!! Works fine for DEM and routing is same as before. Henning On 14.02.2018 22:44, Gerd Petermann wrote: > Hi all, > > Please try r4116 [1] with normal splitter. I hope you don't see any more > crashes in MapSource with the "Show Profile..." button > or corresponding empty "Graphs"

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

Hi Gerd, Maybe it's better to try to merge these small ways as they anyway only creates 'ugly' roads. With increasing level of details in OSM I think mkgmap will need some preprocessing to generalise the data first. I'm not only thinking about these very small ways, but also have the

Re: [mkgmap-dev] Error BeNeLul

ther option like dem-poly to tell mkgmap a polygon. > Points outside of the polygon would get height 0. > I wrote this to Ervin but it seems that I forgor to copy the list. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap

Re: [mkgmap-dev] mkgmap r4022 ready

Hi Gerd, another solution from 'nice looking' point of view except not creating DEM would be to also create sea polygons for the whole rectangle. But I guess it's pretty hard as it needs data tiles, am I right? For users of course it would be better to define an poly-file, where DEM should be

Re: [mkgmap-dev] mkgmap r4022 ready

l see if performance is very different when using compressed files. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Donnerstag, 2

Re: [mkgmap-dev] mkgmap r4022 ready

Hi Gerd, So far I understand you have implemented already cutting the DEM to the map area and just looking for another way to have some larger area for DEM data? I don't see a use case for that. Probably the reason why I first didn't realised the beginning of your svn comment. Henning On 28

Re: [mkgmap-dev] Please test new dem options in r4013 in the dem-tfb branch

Hi Gerd, the generation of the chinese overview map ends with: uk.me.parabola.imgfmt.MapFailedException: There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first.     at

Re: [mkgmap-dev] Please test new dem options in r4013 in the dem-tfb branch

missing hgt files. I am now also adding code to report each file only once. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <o...@hscholland.de> Gesendet: Freitag, 22. Dezember 2017 12:57:17 An

Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data

Hi Gerd, I think the problem is, the reduction ratio is neither depending on the size and amount of nodes. So I doubt there will be good results without somehow analysing the hgt-files or an pre compiled DEM file. But as you said before, it's an minor problem at the moment. Henning

Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data

t > nearly impossible to compare the > resulting bit streams. > Just a matter of time ... > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de

Re: [mkgmap-dev] mkgmap r4010

Hi Gerd, great improovment again! Working now for China :-) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data

map-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Mittwoch, 20. Dezember 2017 17:06:25 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data > > Hi Gerd, > it'

Re: [mkgmap-dev] routing between different maps

Hi Gerd, How much performance does it take? Wouldn't it be better to create those nodes automatically at every level 2 and 4 boundary and give a possibility to define a individual poly for it for any other special case? Henning On 26 Jul 2018, 19:23, at 19:23, Gerd Petermann wrote: >Hi

Re: [mkgmap-dev] Special cases with LocationHook

Hi Gerd. regarding 1+2) I don't see a use case for having country information on natural=land/sea (natural=sea I estimate is generated by natural=coastline). But maybe others do... For my understand those are just used for colouring the map background. In general it would be best, to not

Re: [mkgmap-dev] routing between different maps

Hi Gerd, haven't tried it, but would be surprised if it's supported as it is not the Garmin way... They want you to send all the map tiles by Garmin software to the GPS. But if this can work with mkgmap it's another step. Now we need the non-rectangular tiles...  Henning On 23 Jul 2018,

Re: [mkgmap-dev] Admin relations

to add "in Mongolia" after "the two admin_level 4 ways.". Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Freitag, 13. Juli 2018 06:50 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin r

Re: [mkgmap-dev] Admin relations

Hi Andrzej, yes they are both in and in general it's working. Just on the borders I get these issues. I guess it's because of precision, how mkgmap calculates the area of China. The strange thing is, that the missing red part on Chinese border (Inner Mongolia/Gansu) Is roughly from the center

Re: [mkgmap-dev] Admin relations

Sorry, I just realised after opening tile borders in jOSM, the split is just at tile border. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Admin relations

or that the value is empty. If the value for mkgmap:admin_level2 is empty mkgmap should probably try another node. This doesn't happen. I see no easy way to handle this when the value is set. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet

Re: [mkgmap-dev] Admin relations

Hi Gerd, while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

___ > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Freitag, 12. Januar 2018 13:16:19 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] The 0x4b backg

Re: [mkgmap-dev] DEM file and the block-size option

For overview-map it would be fine for me, but for detailed map I need a block-size of 2k Henning On 13.01.2018 22:57, Gerd Petermann wrote: > Hi all, > > I hesitate to commit this patch because I think that some users create > overview maps > 64MB. > Please check! > > @Steve: I see you are

Re: [mkgmap-dev] The 0x4b background polygon in the overview map

Hi Gerd, ok, maybe I was too fast. ;-) I just tried to understand your Bremen example. You have splitted Lower Saxony (Niedersachsen) into 15 tiles. Based on these 15 tiles you want to let mkgmap create a map of Bremen by using a map polygon, which is not following any of the splitted tiles. Lets

Re: [mkgmap-dev] r4070 in dem-tdb branch

Hi Gerd, thanks for merging it. Hi Steve, I tried it on maps, where I previously had problems with block size. Now these maps compile well without increasing block size manually. Well done! Henning On 18.01.2018 19:14, Gerd Petermann wrote: > Hi all, > > I've merged branch auto-block into r4070

Re: [mkgmap-dev] DEM: performance with bicubic interpolation

u/sites/geocomp99/Gc99/082/gc_082.htm > > Gerd > > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Dienstag, 23. Januar 2018 14:09:17 >

Re: [mkgmap-dev] documentation patch

Hi Mike, are you sure, = needs to be replaced by : in read-config-file? I'm using = and it seems to work. (At least I think/hope so) Henning On 23.01.2018 22:35, Mike Baggaley wrote: > Hi Gerd, please find attached a patch to correct and improve the > documentation of the --read-config command

Re: [mkgmap-dev] Limit the number of highway shields in basecamp and gps

Hi Gerd, Maybe it helps for brainstorming to understand how the Garmin-container is working. So far I understand we take osm-way, shifting each osm-node to closest Garmin-node, this then is written somehow to the map. But how all these information are stored. Is the way-geometry stored once and

Re: [mkgmap-dev] Relation type=area

ys with role upper/lower, > not the ways. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@hscholland.de> > Gesendet: Donnerstag, 1. März 2018 11:28:51 &g

Re: [mkgmap-dev] Relation type=area

But it should be possible to handle it by mkgmap style-file. At least you can copy route-relation tags to ways and it should be similar in that case. Or am I wrong @Gerd? Henning On 01.03.2018 15:33, demon.box wrote: > Hi Gerd, thanks very much for your answer but what a pity... it means that at

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

How about merging ways shorter than 1 unit if they are similar or deleting them and move access to the node? Or just delete such ways only going force and back. And moving access to the node. Henning On 9 Mar 2018, 16:15, at 16:15, Gerd Petermann wrote: >Hi

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

n ways are not similar. > >I think best is to collapse the way. In a later step (after or when >merging) mkgmap may decide that the way can be removed. >I am working on this now, just have to find the right criteria... > >Gerd > >________ >Von:

Re: [mkgmap-dev] overlapping highways and route restrictions

shing that some of these errors exists since >years, esp. in well mapped areas. >I tried to find the source code for OSM Inspector but it seems this is >closed source owned by Geofabrik? > >Gerd > > >Von: mkgmap-dev <mkgmap-dev-boun...@li

Re: [mkgmap-dev] overlapping highways and route restrictions

Hi Gerd, I would ignore them and write a warning/info. Of course mkgmap could try to handle it, but I don't think it's worth. Better fix it in the data,which anyway needs to be done. Henning On 4 Apr 2018, 17:11, at 17:11, Gerd Petermann wrote: >Hi Felix, >

Re: [mkgmap-dev] overlapping highways and route restrictions

It seems to be more easy to promote OSM Inspector and fix those faults...  Henning On 4 Apr 2018, 21:55, at 21:55, Gerd Petermann wrote: >Hi Felix, > >Maybe we have different ideas what merging of labels means. >With r4149 I've implemented this: >If way w1 has

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

it right >now. Seems my Mainboard is dead. So I probably won't have possibilities >for testing before Monday or Tuesday. > >On 23 March 2018 at 09:39, Gerd Petermann ><gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> >wrote: >Hi Henning, > >Hen

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

should be easy. > >Gerd > > >Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von >Henning Scholland <o...@hscholland.de> >Gesendet: Donnerstag, 29. März 2018 13:48:46 >An: Development list for mkgm

Re: [mkgmap-dev] battery low because of DEM?

Hi Gerd, I had similar effect, but also haven't investigated further. As it was during my hike quite cold outside and the eneloops were for longer time around 0°C so I thought this might be the reason. I hope on my April hike, the temperatures are more warm. I will let you know about it. Henning

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

t; >I might still add code to print warnings for the case that (too) many >arcs with the same heading are connected to one node, if you want that. > >Gerd > > >Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von &

Re: [mkgmap-dev] Bug in Road Merging - actually doubling roads.

Hi Gerd Doesn't it cause problems at roundabouts for messages like 'leave at 3rd exit' Henning On 22 Mar 2018, 23:56, at 23:56, Gerd Petermann wrote: >Hi Felix, > >I tried to remove duplicate arcs but that is probably not allowed. >Mapsource says that there is

Re: [mkgmap-dev] Example of logging Echotags to file

Hi Joris, I'm using java 1> mkgmap.log 2> mkgmap_error.log In that case you will find the echo-tags in mkgmap-error.log together with all other error-messages send to stdout. Henning On 24.03.2018 13:11, Joris Bo wrote: > > Hello > >   > > Does somebody have an example of logging the

Re: [mkgmap-dev] documentation improvement patch

Hi, Maybe it is a good idea to introduce some switch like 'just create a simple map'='for Garmin device and BaseCamp' , where mkgmap is always doing, what is currently best practice and new people get easily a map eg. for copying to their Garmin device or Basecamp or MapSource. So he don't need

Re: [mkgmap-dev] documentation improvement patch

pi >gmapsupp >nsis >... (to be defined) > >Do we really need more? > > > > > >____ >Von: mkgmap-dev im Auftrag von >Henning Scholland >Gesendet: Montag, 11. Februar 2019 10:10 >An: Development list for mkgmap >Betre

<    1   2   3   4   5