I'd prefer not to change the syntax because that would break backward
compatibility.
Attached is a small patch which allows to use height without an argument. If an
arg is given it must use
ft or feet as target. The doc is changed accordingly.
I've also tried to fix a problem in the docu for con
Hi
I'm attaching a patch to remove indexes for labels 0x28xx from MDR file.
I don't think any GPS supports these indexes.
Well I don't mind applying the patch as no one seems to have objections.
However there must be maps that have that group in, as I've explicitly
added it separate from the
Hi Andrzej
That is exactly right.
In particular I agree that it should be {ele|height:m} as it
has to have feet as the target unit. Since the default unit in OSM
is meters even the :m part could be defaulted.
..Steve
some guessing on my part, hope someone corrects if I'm wrong.
As I underst
+1. BTW, comma is also standard decimal separator in Spain, and also a
usual error in data here.
El 02/02/17 a las 16:38, Andrzej Popowski escribió:
Hi Carlos,
maybe mkgmap could issue a warning for filter whenever input data are
not compatible? Comma is a standard decimal separator in Poland
Hi Gerd,
the expected outcome of this patch is no change in img but some data
omitted in MDR index. This should be:
- for Mdr4 POI type 0x28 is omitted
- for Mdr10 and Mdr11 indexes for POI type 0x28xx are omitted,
- for Mdr15 labels for POI type 0x28xx are omitted.
Patch looks like a simple c
Hi Carlos,
maybe mkgmap could issue a warning for filter whenever input data are
not compatible? Comma is a standard decimal separator in Poland and
there is a lot of erroneous tags. I haven't noticed this problem until now.
When numeric value contains a comma, filter "height" doesn't convert
El 02/02/17 a las 15:24, Andrzej Popowski escribió:
Hi Gerd,
warning is OK. I hope filters with the same units for source and
target work too. They would be convenient to remove unit shortcut from
tag.
Another suggestion for default style, support for comma as decimal
separator:
natural=p
El 02/02/17 a las 14:06, Andrzej Popowski escribió:
Hi Carols,
some guessing on my part, hope someone corrects if I'm wrong.
As I understand, elevations in img are stored in feet.
Filters hight:m=>ft and conv:m=>ft indicate, that value from source
has to be converted into feet, as expected by
Hi Gerd,
warning is OK. I hope filters with the same units for source and target
work too. They would be convenient to remove unit shortcut from tag.
Another suggestion for default style, support for comma as decimal
separator:
natural=peak {name '${name|def:}${ele|subst:,=>.|height:m=>ft|d
Hi all,
Andrzejs findings sound logical to me. I propose to add a check which prints an
error
message if height is used with a target unit other then ft:
Error in style: Error: height filter reqires ft (feet) as target unit: 'ft=>m'
and I can add a corresponding hint in the doc.
OK?
Gerd
__
Hi Carols,
some guessing on my part, hope someone corrects if I'm wrong.
As I understand, elevations in img are stored in feet.
Filters hight:m=>ft and conv:m=>ft indicate, that value from source has
to be converted into feet, as expected by img format.
When you look at map, you see height u
Not sure. I think the that the values for contourlines work like this. I'll
experiment with the values later.
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
Gesendet: Donnerstag, 2. Februar 2017 11:44:42
An: Development list for mkgmap
Betreff: Re:
I thought the special character was the comma that is added after the
name. So there is some internal character that may affect displayed
units, right?
El 02/02/17 a las 11:31, Gerd Petermann escribió:
Hi Carlos,
I forgot to mention that the special separation character added by the height
f
Hi Ticker,
okay, I wait for yor results. Besides that I think the de-duplication should
better be done in StyledConverter.
Gerd
Von: Ticker Berkin
Gesendet: Donnerstag, 2. Februar 2017 11:36:31
An: gpetermann_muenc...@hotmail.com
Betreff: Re: [mkgmap-de
El 02/02/17 a las 11:31, Gerd Petermann escribió:
In your examples the rule doesn't place the argument in "", maybe that is the
problem?
The rule is copied from default style. Adding " " doesn't make any
difference.
___
mkgmap-dev mailing list
mkg
Hi Carlos,
I forgot to mention that the special separation character added by the height
filter might tell Garmin softtware
to convert the value (again). IIRC there is a flag in the img file which tells
Garmin if values are in feet or metres, so
you are probably right that the filter doesn't wor
Hi Carlos,
this seems to be a problem in the documentation. I found this description for
the height filter:
"This is exactly the same as the conv filter, except that it prepends a special
separation character before the value
which is intended for elevations."
${ele|height:"m=>ft"}
This can be
According to style manual the rule
natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616
resolution 24]
from default style should convert ele values from meters to feet,
assuming ele is in meters, but this is what map shows for the following
ele values:
ele=500, map: ", 500 m"
el
Hi Ticker,
I did some more tests with r3782, also with other styles like that for
openfietsmap.nl (by Minko aka ligfietser)
http://mijndev.openstreetmap.nl/%7Eligfietser/openfietsmap/Scripts/Styles/
I've compared the results with trunk version r3773 and noticed that the branch
produces fewer
me
Sorry, I meant Steve Ratcliffe, not you.
Gerd
Von: mkgmap-dev im Auftrag von Steve
Sgalowski
Gesendet: Donnerstag, 2. Februar 2017 09:20:35
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] POI indexing, problem with label 0x2800
how did you wi
how did you wish me to run a test on poi , as i have a 3rd party program
that uses splitter and mkgmap
stephen
On Thu, Feb 2, 2017 at 6:09 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Andrzej,
>
> thanks for the patch. I asked Steve to have a look at this but he seems to
>
Hi Andrzej,
thanks for the patch. I asked Steve to have a look at this but he seems to have
no time.
My knowledge about index structures is nearly zero, so I have no idea how to
verify the effect of the patch.
Gerd
Von: mkgmap-dev im Auftrag von Andrze
22 matches
Mail list logo
