Elevation: round/chop?

[grums]

Can Elevation values be made into integers using MC?
I see the Ersetzung Pässe mit Höhenangabe darstellen which is desirable, but how do I cut away the decimals (if present)?

Background: https://forum.openstreetmap.org/viewtop ... pid=743447

[grums]

Nop,

in the thread referred to in my first post the answer is I think it uses mkgmap and therefore you might edit the style rules to use rounded values - where it is Map Composer.

Is he right, and if so: are these style rules under my control or buried in your java libraries?

I know that I can just switch off the elevation display, but...

Regards, grums

[Nop]

Right now there is no support for trimming excessive digits. All tags are just handled as texts. Also the replacement rule for elevation values is not aware that in this particular case the text contains numbers.

So this would either need to be handled by a special case in Java Code or by fixing the nonsensical values in the OSM database.

As a quick workaround you might try the following:
- generate map as usual
- modify the generated mkgmap ruleset in mapstyle/points (but your changes will be overwritten when you generate with MapComposer again)
- run the mkgmap command again manually. You find all commands composer used for map generation in commands.log

Of course the more helpful approach is fixing the mistake in the database because it benefits all maps and other uses.

[grums]

I agree that the best approach is to change the OSM data.

I skimmed through the mkgmap style manual: http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf but I can't see any obious way to truncate or round a value...

Maybe an OSMOSIS transform (https://wiki.openstreetmap.org/wiki/Osm ... _transform) on my copy of the Planet files could do the job?
If it's possible, then the best/easiest (for me) would be to have MC do the transform (if present, user-specified) during the cut phase - the next best would be to manually transform each locally stored Planet file when I download a new copy.

What do you think? I'm a complete newbie to both mkgmap and OSMOSIS, but I'm willing to give it a shot and report back here (and in the original tread).

Regards, grums

[grums]

I managed to transform a small osm.pbf clip, stripping decimal point and decimal(s) in all ele tags:
osmosis --read-pbf file=malaga-ORIGINAL.osm.pbf --tag-transform file=ele-nodecimals.xml --write-pbf omitmetadata=true file=malaga.osm.pbf

ele-nodecimals.xml:

Code: Alles auswählen

<?xml version="1.0"?>
<translations>
  <translation>
    <name>ele-nodecimals</name>
    <description>strip decimals from elevation values</description>
    <match mode="or">
      <tag k="ele" match_id="m" v="(.*)\..*"/>
    </match>
    <output>
      <copy-unmatched/>
      <tag from_match="m" k="ele" v="{1}"/>
    </output>
  </translation>
</translations>

I'm sure the OSMOSIS command can be improved: my output file is a bit larger than the input...

The europe.osm.pbf is quite large (~20GB), so I'm not immedietely tranforming it - can/is this translation mechanism be included in a future release of MC?
You could supply a dummy filter with <copy-all/> in <output> section, then the user can create a filter if needed.

Regards, grums

[Nop]

I skimmed through the mkgmap style manual: http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf but I can't see any obious way to truncate or round a value...

In section 4.4.1. Variable filters, the operation conv and part sound like they could do the job.

Osmosis is also a very powerful tool, your solution should work. If the europe file is too large, you can also let composer cut the data first, then apply your fix to the *_input.pbf created by composer, then let composer run.

Or you can copy the lines from command.log where composer calls osmosis and add your fix as an additional parameter directly there. You wouldn't even loose any time for two osmosis passes that way. Then execute the cutting manually and let composer process the output.

I will not include anything like that in Composer. As this is a clear error in the data it should be fixed in the data. If it is a necessary operation for map design, I would include it in composer. But mixing complex osmosis operation in with the automatism of composer would defy the idea of creating an easy-to-use GUI tool.

[grums]

Thanks, Nop

I think you misunderstood my suggestion for a new feature in MC: i never intended you to code anything to circumvent this problem, my suggestion was of a more general character: would you enhance the osmosis command to include extra, user-specified parameters, in this case a transform?
Maybe make user-specified parameters for osmosis available as part of the configuration.

Anyway, you have suggested a number of other opportunities to choose from, I'm grateful.

Regards, grums

[Nop]

There is even one more elegant workaround:
- separate your job into two
- the second has only the composer and mkgmap operations as usual
- the first has only data download and cutting enabled
- you can add a script to be run after the job (in the second tab). Add your osmosis script here, processing *_input.pbf

Alternatively, you can disable cutting in composer and add the combined script (cutting taken from command.log and your tranform added to it).

I think I understood you very well. But as I said, mixing the GUI level operations of composer and command-line operations of the tools working in the background would increase the complexity a lot. And while osmosis is powerful, getting the chaining of operations right can be very tricky.