Well to make styles easier, maybe we could have a third command which
works like a in between add and set.
That command would only set mkgmap: tags, in case they are not default,
therefore you could later on in the style run rules with differentiation
between set explicitely by set, and other se
On 13.09.2013 22:52, WanMil wrote:
>> okay, finally I managed to rewrite my style -- woohaa - neded about 10
>> hours of CTRL-H and controlling the results
>
> Wow, you seem to have an epic style :-)
well that happens if you always add rules as mkgmap gains features,
maybe at some point I sho
hi!
Yes, it happens every time. Did you compile your maps with --gmapsupp
switch? Both my scripts use it, also stack trace shows:
at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish
I use custom map extract (Poland and some border terrains of Germany, Czech
Republic, itp):
http://garmin
Will this patch be part of the regular release?
RocketMan
- Original Message -
From: "WanMil"
To: "Development list for mkgmap"
Sent: Thursday, August 29, 2013 9:22 PM
Subject: [mkgmap-dev] [PATCH v2] Move maxspeed calculations to style file
> The patch moves the road speed calculat
Having a look at taginfo I guess that non case sensitive checking is not
required:
http://taginfo.openstreetmap.org/keys/oneway#values
http://taginfo.openstreetmap.org/keys/bridge#values
http://taginfo.openstreetmap.org/keys/tunnel#values
http://taginfo.openstreetmap.org/keys/access#values
http://
> okay, finally I managed to rewrite my style -- woohaa - neded about 10
> hours of CTRL-H and controlling the results
Wow, you seem to have an epic style :-)
>
> I just noticed that versus the patched version of mkgmap trunk filesize
> increased by about 1%. Overall the rendering speed made
okay, finally I managed to rewrite my style -- woohaa - neded about 10
hours of CTRL-H and controlling the results
I just noticed that versus the patched version of mkgmap trunk filesize
increased by about 1%. Overall the rendering speed made no difference or
maybe even increased 1-2% (well
I didn't see any speed improvement. Could you recheck if there is really
any improvment - and only if so, implement it?
Or at least have Yes and yes and YES all valid, for true, which is
usually never the correct value in OSM, maybe we could be case sensitive
(but actually I would prefer to keep
okay, I quickly checked out some routes - but so far only in Mapsource.
Seems the long distance routing on the branch is quite a lot better than
with the old patch.
E.g. same route calculated but on 1. try instead of 3. try. And 165
instead of 181 intersections (or better directions in Mapsource
Postal Code Filters only seem to apply to NT imgs not the ones created using
mkgmap.
--
View this message in context:
http://gis.19327.n5.nabble.com/converting-post-codes-to-cities-tp5776958p5777494.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_
I have tried using
mkgmap:postal_code=* & mkgmap:area2poi=true { add place=city; set
name=$(addr:postcode); delete addr:postcode }
but I am getting a lot of "point number to big" error messages and map
compilation fails, is there a limit to the number of poi in a map ?
I also have in the osm fil
On 13.09.2013 08:46, Felix Hartmann wrote:
>
> On 12.09.2013 20:58, WanMil wrote:
>
>>> Felix, you're welcome :-)
>>> Getting such comments is the reason to implement and test these new
>>> features in a branch.
>>> I can easily add handling for mkgmap:access=no into the java sources.
>>>
>>> That
12 matches
Mail list logo
