Hi
I just realised that in the default polygon style construction, whether its
residential or industrial , is always defined as industrial 0x0c.
I understand the' logic' , in that there are many 'mobile' industries
constructing residential or industrial buildings.
In my city there are numerous
Yes, I think that would work.
I forgot to mention another use case. highway>residential which lies
inside residential areas. They have typically maxspeed lower than
outside residential areas, but are not correctly tagged in many cases.
Proposed filter could be used to lower maxspeed for those w
Hi Carlos,
I see a performance problem if mkgmap has to evaluate that for each element.
I think it would be better to have a special tag like mkgmap:remove-if-in=
which would tell mkgmap to find out if the object lies (completely) within a
polygon
that has the given type. This can happen after pr
One matter that has been discussed several times on this list is the
need to remove buildings. While removing buildings is becoming
absolutely necessary in many cities, due to massive building imports, it
may be quite convenient to keep them at rural or low densely populated
areas. Would it be
Hi Carlos,
yes, sorry, I forgot to hardcode the m. I understood your post so that you want
to hardcode the m value
and that meter should be the only unit.
I agree that it seems impossible to get the Garmin translated value in the
format you want.
Gerd
Vo
Hi Ticker,
Ticker Berkin wrote
> I can't do anything for a couple of days but I'd like to combine the
> methods.
sounds good to me. I once analysed why sub divs were split and found that
most times it was because of "too many points" or "too many lines", not
because
of "too much data in rgn", but
There's no way. With your rule Garmin doesn't recognize ele_in_m value
as an elevation and so units are not displayed. I could hard code an m
of ft unit to be shown, but then user could not change it in settings. I
was already using a rule with the same problem:
ele ~ '.*feet' { set ele='${ele|
Hi Gerd
One of the reasons I went along the PredictPoints route is that MapArea
was calculating the subDivision usage (number of items, amount of data)
based on totally unfiltered lines/polygons, regardless of the
resolution, so this was forcing splits where no need whatsoever.
I didn't want to a
Hi Carlos,
to answer your question: my understanding is that you should not use the
height filter.
I did not try but I think something like conv:m=>ft|conv:ft=>m should extract
the raw
value in m, so maybe something like this:
ele=* {set ele_in_m='(${ele|conv:m=>ft|conv:ft=>m})'
natural=peak {n
Hi Carlos,
it seems that the Garmin software is interpreting a value with the prefix
"\u001f"
to format it as something lije ", " + convertFeetToWantedUnit(value).
BTW: I found some routines im mkgmap which treat these prefixes special, e.g.
Label.stripGarminCodes(String s), but those are called
Hi Ticker,
attached is a patch based on r3777 which implements my idea of backtracking, see
gis.19327.n8.nabble.com/Multipolygon-Relation-checks-in-mkgmap-tt5889908.html
I think this is the better way to implement the split at high prec. It's based
on r3777 because
that was the last version with
Current rule for peaks using height: filter results in peaks named in
the form "name, ele m" (of ft according to your settings). I would like
show peaks formated as "name (ele m)". I've been playing with line "s =
"\u001f" + s;" in HeightFilter.java adding parenthesis in different
ways, but not
Hi Ticker,
I think the problem is that PredictFilterPoints ignores the fact that the
DouglasPeuckerFilter typically reduces the number of nodes.
The result is that many shapes are split although they would not have too many
points after DouglasPeuckerFilter.
Gerd
___
13 matches
Mail list logo
