[mkgmap-dev] [PATCH] Enable elevation profile in MapSource

Mon Feb 15 21:48:46 GMT 2010

Am 15.02.2010 22:13, schrieb Felix Hartmann:
>
>
> On 15.02.2010 21:30, Ronny Klier wrote:
>> Am 15.02.2010 12:02, schrieb Felix Hartmann:
>>
>>> Okay here are my results (actually the same as with gmaptool, I did not
>>> notice that "how" profile can be shown).
>>>
>>> 1.Only normal map without contourlines:
>>> Mapsource/Basecamp "show profile" is greyed out.
>>>
>>> 2. Only contourline map:
>>> Working in both: Mapsource 6.13.6, 6.15.11 as well as Basecamp 2.0.8
>>>
>>> 3. Mixed map made out of .img with osm mapt data and .img with
>>> contourlines (joined using: java -ea -jar -Xmx512M mkgmap.jar --index
>>> --description=%srtm% --route --country-abbr=%abr%_srtm
>>> --country-name="%date%_srtm" --mapname=%FID%0000 --family-id=%FID%
>>> --product-id=1 --series-name=%srtm% --family-name=%srtm% --tdbfile
>>> --overview-mapname=mapset --area-name=%country% 6*.img 7*.img :)
>>> Mapsource 6.13.6 on clicking on "show profile" empty profile comes up.
>>> Mapsource 6.15.11 clicking on "show profile": crash
>>> Basecamp: Clicking on elevation profile: Message "The current map does
>>> not contain any elevation data on the selected route".
>>>
>>> 4. Normal map including contourlines (contourlines as osm file merged
>>> with normal osm file using osmosis):
>>> Profile working in Mapsource/Basecamp. This is a lot of work and time.
>>> Also not legally possible with srtm data from viewfinderpanoramas.org.
>>>
>>>
>>>
>>> Is anyone able to get 3. working (without loosing autorouting)?? Does
>>> the patch have any effect on the .img (if so I would try to recompile my
>>> .img contourlines)
>>> Currently I need to seperate installs:
>>> Meaning both map as described and 2. and 3. I calculate my route on 3.,
>>> then switch to contourline only map, and now clicking on show profile
>>> (only in Mapsoruce 6.15.11/Basecamp, not however in 6.13.x) a nice
>>> profile is shown. In Mapsource 6.13.6 I am not able at all to get a
>>> profile shown. (have not yet tried on GPS, but I think map as described
>>> under 3. would work for both autorouting and profile).
>>>
>> There is no change to the img files.
>>
>> I tryed scenario 3. and got the same problems. I think MapSource gets
>> confused having two img's for the same area. Knowing this scenaro its
>> required to have an option to turn it off.
>>
>> Until now I created my maps as described in 4. But using a fix
>> areas.list from splitter so I had not to rebuild contour lines osm again
>> and again.
>>
>> Actually I am working on the integrated contour line feature of mkgmap.
>> It failed if a map didn't fit in a single DEM data file (SRTM, CGIAR or
>> ASTER). For SRTM data I am now able to cover larger areas. The time went
>> up from around 1.5 hours for my germany generation to 2 hours not
>> counting the time previously required to generate and merge elevation
>> osm with srtm2osm and osmosis. So this approach seems to be not slower
>> and saves disk space.
>>
> Well if it were possible the best way to use it would be....
>
> If mkgmap could do the merging. Of course it is clear that one has to
> cut down on the max-nodes a bit more, but except the Alps excerpt from
> Geofabrik, all regions are pretty easy.
>
> There would be several ways that I would think of as very successful:
> a) mkgmap accepts osm AND .img as input, and simply takes the
> contourlines from the .img and adds them to the tiles after the normal
> osm data has been written. This would of course require support for
> reading in .img files (but I think it should not be to much work to
> implement if one limits this to plain lines without routing, indexes and
> so on read in.
> b) Compiling to img from mp for Contourlines my PC needs 8 minutes for
> all of Europe (Germany is 35seconds). So for a) simply exchange .img
> input by mp input.
> c) make mkgmap combine .img files. That would be the nicest solution.
> d) make mkgmap able to write out 2 osm files into one single .img. That
> should be the easiest solution.
>
> Above scenario 3 has the added problem that sometimes the contourlines
> do show up in Mapsource, sometimes not. Reopening/Closing Mapsource
> changes the situation. I don't know how to get contourline .img shown
> permanently on top of the other maps (simply using higher ID does NOT
> work, even more strange if I feed mkgmap with java mkgmap.jar ....
> 6*.img 7*.img with 7*.img being the contourlines it sometimes works, If
> I change the command around to java mkgmap.jar .... 7*.img 6*.img the
> contourlines are never on top in Mapsource; the only thing that seems to
> work always is to run java mkgmap .jar ..... *.osm *.mp)
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>

These ways would be great still they are not related to what the contour 
lines part of mkgmap does ;-)

I am with you: d) should be the simplest to implement (Not knowing whats 
really neccessary for this to work). I think everything which involves 
reading img files is a lot harder because the file structure seems not 
to be straight forward readable.