Hello Mark,
motor_vehicle is not understood by mkgmap
Actually, why not? If my memory serves right, mkgmap understands
motorcar and motorcycle (and maps them to the same access bit), but why
not motor_vehicle? For example in my understanding, tractors are
covered by motor_vehicle but not
Hi WanMil,
I didn't get any negative feedback. Could you please commit this
patch?
You did get some feedback from me, but it is not that critical. I
committed the patch in trunk r1575.
Thank you for your ongoing efforts,
Marko
___
Hi WanMil and others,
Some time ago, there was discussion that the MultiPolygon code in
mkgmap should tag the lines that it generates when splitting
multipolygons to polygons.
I think that there is a genuine need to split large multipolygons to
smaller multipolygons in the OSM data too.
Hi WanMil,
Regarding your questions I reply with some other questions:
* Why do you split large multipolygons to smaller ones?
I am expecting problems with some tools. Let us assume that Lake Saimaa
is consists of 1 ways with an average 300 nodes per way. If it were
a single
Hi WanMil,
the patch for the mp code does not remove any tags from the source
polygons and lines. Instead it tags all mp-source lines and polygons
with mkgmap:mp_source=yes.
All artificially created polygons during the mp processing are tagged
with mkgmap:mp_created=yes.
Example:
Hi Maning,
http://www.openstreetmap.org/user/bri%20g/diary/9588 wrote:
Okay let me explain, if I store the point of exactly where I am that
works, but usually I move the pointer to where the data point is, say
a post box on the other side of the road, but that is in in an area,
so the Garmin
Hi WanMil,
if you want to know exactly what's happening please start mkgmap with
debug-level FINE. I don't do anything else. I am happy for any good
hint what might be a problem. But I don't investigate every warning
of the mp code.
Fair enough. For now, I will blame it on the
Hi Maning,
My typ file is not incluced when I created a gpamsupp file from a
previous mkgmap run
[cut]
time java -Xmx1512m -jar mkgmap.jar --gmapsupp some_dir/*.img
some_dir/MINIMAL.TYP
I read somewhere that the TYP file must be in the current directory.
Have you tried that?
Hi David,
I know some of you are looking for a tool which could produce TYP
file. I was on the same way since last december. This may help you...
http://emerald-island.eu/wikka/MakeTyp
Thank you, I am glad that I did not start writing any TYP file
definitions in assembler yet.
Written
15.02.2010 15:07:01, Garvan maew kirjoitti:
Turn restrictions do not seem to work with mp file input. Would this
be difficult to add?
How would you represent turn restrictions in MP files? Does the MP
format support relations? For what it is worth, multipolygons are
implemented as
Hi WanMil,
2nd: the multipolygon code should not remove the boundary tags from
the singular ways. Additionally the polygons created by the
multipolygon code could be tagged with mkgmap:mp_boundary=yes. This
tag could be evaluated in the style definition so the style could
differ
Hi WanMil,
I downloaded the finland OSM dump from geofabrik from today (Feb
15th).
I used splitter v105 and the areas.list file from
http://www.polkupyoraily.net/osm/ to get three tiles.
Then I tried that patch:
* I got no warning for mp 404644
* I got only one unknown reason warning for
Hi Clinton,
On Feb 14, 2010, at 11:32, Minko wrote:
set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' |
'${name}';
Just out of interest, should the parentheses surrounding
mkgmap:boundary2_name not be curly brackets ('{', '}')? I noticed this
in the default style as well. Or
Hi WanMil,
Compared to v3 (posted by Carlos in thread Wrong multipolygon
warnings) some unused debug messages have been removed.
The patch enables the multipolygon code to process multipolygons with
overlapping lines.
For the Geofabrik Finland extract of today, the patch reduces the
On Thu, Feb 11, 2010 at 07:59:01PM +0100, WanMil wrote:
The Osm5XMLHandler sometimes throw a NullPointerException in line 397.
This is the key.equals(highway) part:
if((val.equals(motorway_junction) ||
val.equals(services))
key.equals(highway))
{
Hi Matteo,
If a riverbank intersect a landuse, the riverbank should be drawn on top of
the landuse.
See the attachment for an example.
(Why) can't you define a multipolygon that cuts out the riverbank from the
landuse?
I am afraid that mkgmap would become a lot more complex if it allowed a
On Mon, Feb 08, 2010 at 01:30:13PM +, Chris Miller wrote:
What might be nice is if this stripping can be done before (or during) the
split. That way the splitter would have to do less work, and possibly would
also be able to perform a better split. The downside would be that any style
On Sun, Feb 07, 2010 at 09:33:40AM +0200, Marko Mäkelä wrote:
The Inarinjärvi multipolygon that I defined yesterday was rendered fine,
except for one minor detail: A lake within an island was incorrectly
named Inarinjärvi. I have now removed name:* from the multipolygon relation.
Hopefully
On Mon, Feb 08, 2010 at 12:47:50AM +0100, Ronny Klier wrote:
I think there is a bug in label encoding in Format6Encoder. For some
string length the last encoded byte is not stored.
E.g. having a string 10007 the encoded byte buffer looks like this
[0] [0x86]
[1] [0x8]
[2]
Hi Mark,
On Sat, Feb 06, 2010 at 12:40:10AM +, Mark Burton wrote:
Hi Toby,
Can we also try to infer through-routes from the presence of a 'route'
relation containing the ways?
Is that going to work? Just because a route uses a particular
combination of ways, it doesn't follow
Mark, WanMil,
It seems that the anti-island check got the piecewise defined coast line
of Inarinjärvi (Lake Inari) wrong. I now defined a multipolygon for the
lake and its about 700 islands, hopefully making no mistake in the process:
http://www.openstreetmap.org/browse/relation/402543
Some
Hi Toby,
On Sat, Feb 06, 2010 at 11:58:23AM +, Toby Speight wrote:
Marko What do you think? Should I remove the rules for left:*, right:*
Marko names from the default style, or should I just add a comment to
Marko the effect that these are deprecated, see the 'relations' file
Marko and
Hello Mark,
It seems that the anti-island check got the piecewise defined coast line
of Inarinjärvi (Lake Inari) wrong. I now defined a multipolygon for the
lake and its about 700 islands, hopefully making no mistake in the process:
http://www.openstreetmap.org/browse/relation/402543
The Inarinjärvi multipolygon that I defined yesterday was rendered fine,
except for one minor detail: A lake within an island was incorrectly
named Inarinjärvi. I have now removed name:* from the multipolygon relation.
Hopefully the code will do the right thing and copy the name:* from the
outer
On a related note, I was driving a car today (untypical of me, since we
do not have one), and got a turning prompt where the twoway
highway=secondary became a dual carriageway, entering
http://www.openstreetmap.org/browse/way/4492154
from the east. The transition is seamless on the road.
Hi Steve,
On Fri, Feb 05, 2010 at 04:37:58PM +, Steve Hosgood wrote:
Marko Mäkelä wrote:
On a related note, I was driving a car today (untypical of me, since we
do not have one), and got a turning prompt where the twoway
highway=secondary became a dual carriageway, entering
http
On Thu, Feb 04, 2010 at 08:50:49PM +0100, WanMil wrote:
I have doubts if that's a good idea.
If multipolygons are splitted by splitter it is possible that some
polygons are dropped because they are not inside the tile bounds.
This makes it possible that the outer ring survives only.
The
On Tue, Feb 02, 2010 at 11:34:50PM +0200, Marko Mäkelä wrote:
I can suggest two solutions to this issue:
* splitter should flag and preserve all nodes that belong to ways that belong
to multipolygon relations (I would not care about route relations, for
example)
* mkgmap should discard
Hi Chris,
It's not a straightforward fix in the splitter however I'll see what I can
do. I think if I make the cache generation compulsory it will be possible
to handle this without too serious an impact on performance.
I understand that this would require deferring the writing of the nodes
On Tue, Feb 02, 2010 at 09:39:56AM +, Steve Hosgood wrote:
As a note primarily for Steve Ratcliffe(*): it might be an idea to
include a boilerplate .SRT file in the .IMG files generated by mkgmap.
If this is done it is possible that the .SRT file will get loaded to the
GPS units and
Hi WanMil,
can you please investigate this:
2010/02/01 09:05:31 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon
4611686018427388326 intersects itself.
2010/02/01 09:05:32 WARNING (MultiPolygonRelation): 63240001.osm.gz: The
polygon is composed of
2010/02/01 09:05:32 WARNING
Hi WanMil,
On Sun, Jan 31, 2010 at 09:21:28PM +0100, WanMil wrote:
* More specific warnings for multipolygons (intersections, exchanged
inner/outer roles)
* Self intersecting polygons are now handled as multiple polygons
instead of using only the first polygon
* Inner polygons that are
Hi WanMil,
On Sat, Jan 30, 2010 at 09:46:56AM +0100, WanMil wrote:
The mp code warns if a polygon intersects itself.
+ if (log.isWarnEnabled()) {
+ if (area.isSingular() == false) {
You might write this as log.isWarnEnabled() !area.isSingular()
and get rid of
Hi WanMil,
The generation of the sea polygons with
--generate-sea=multipolygon,no-sea-sectors sometimes still produce
flooded areas.
What are the sea sectors good for, and why are you disabling them?
1. Some of the inner polygons generated for the seabounds mulitpolygon
sometimes are
Hi WanMil, Mark, all,
I analyzed all the multipolygon errors and warnings I got for today's
finland.osm.bz2 from Geofabrik, without --generate-sea.
Most of them can apparently be blamed on missing boundary information.
I wrote the relation IDs an explanations to my logging.ignore file, so
that
I am compiling mkgmap with Sun javac with -Xlint:unchecked
by commenting out the compilerarg definition in build.xml,
and I get some warnings for unchecked calls and type conversions.
I do not know Java well enough to fix these (I learned it before
the generics were introduced and have not written
Hi WanMil,
This mp was changed today (Jan 29th 2010, 06:33). Before the change a
small polygon in the north of the mp touched the outer ring. So it
contains to your first category overlapping lines.
Thanks for figuring this out. I was too lazy to check previous versions,
and the Geofabrik
Hi Mark,
Can you please check to see whether this location is situated very
close to the corner of a tile? I am guessing that the coastline cuts
the corner of a tile and so you end up with nodes on each of the tile's
edges at the corner.
Like I wrote in the message you replied
Hi Mark,
On Thu, Jan 28, 2010 at 07:01:06PM +, svn commit wrote:
Version 1533 was commited by markb on 2010-01-28 19:01:06 + (Thu, 28 Jan
2010)
Add marine style for making nautical maps.
Provides fairly complete support for the seamark tag set.
I see that you defined
On Thu, Jan 28, 2010 at 08:56:42PM +0100, WanMil wrote:
Current mp implementation does not remove polygon tags from unclosed
ways. I have observed that the unclosed polygons sometimes are closed in
a later step of mkgmap. This causes flooding of areas around seas.
Finnland is a great
On Wed, Jan 27, 2010 at 05:38:40PM +0100, Felix Hartmann wrote:
I still have big problems with the search index when using --latin.
I am too having problems with --latin1, but different ones:
The street name labels that run along the streets (or as tangents to
the lines) and the place names
On Thu, Jan 28, 2010 at 08:07:56PM +, Mark Burton wrote:
What happens if you use polygons rather than multipolygon for the sea
generation? If it still floods with polygons, the problem is in the sea
code, not in MP code.
It floods. I can't remember if I ever tried generate-sea with the MP
Hi Mark,
Err, that message is not in r1533 - something's screwy!
Sorry for the noise then. I did ant clean; ant dist now.
I wonder if something is broken in ant's or javac's dependency detector.
By the way, --generate-sea complains, even though the help blurb
says that multipolygon should be
On Thu, Jan 28, 2010 at 09:56:23PM +0100, WanMil wrote:
Another solution could be that ways get an used by mp tag so that
other steps in mkgmap don't try to autoclose these ways. This would give
a chance to option 2.
Could you do the equivalent of apply {set mkgmap:mp='${id}'}
or apply {set
Hi Mark, WanMil,
On Thu, Jan 28, 2010 at 10:53:33PM +0200, Marko Mäkelä wrote:
Hi Mark,
Err, that message is not in r1533 - something's screwy!
Sorry for the noise then. I did ant clean; ant dist now.
I wonder if something is broken in ant's or javac's dependency detector.
Oh, now I
On Tue, Jan 26, 2010 at 11:06:41PM +0100, WanMil wrote:
The patch reduces the error messages in case some polygons intersects or
overlaps to warnings. Additionally all ways that are completely outside
the bounding box are no longer processed.
This is a result of the discussion
Hi Mark,
On Tue, Jan 26, 2010 at 10:53:48PM +, Mark Burton wrote:
Hi Marko,
Please try the attached patch and see if it gets rid of the can't be
merged error you are getting when generating sea.
Sorry, no dice. I still see several of the warnings, including the one
that I reported
Hi WanMil,
thank you for having a look.
On Tue, Jan 26, 2010 at 07:05:39PM +0100, WanMil wrote:
On Mon, Jan 25, 2010 at 09:39:56PM +, Adrian wrote:
I don't think these warnings are bogus. Mkgmap definitely has problems
with multipolygons. The Languedoc-Roussillon extract (southern
Hi Mark,
On Tue, Jan 26, 2010 at 05:51:07PM +, Mark Burton wrote:
v2 - now checks to see if an anti-island is surrounded by water or land.
If surrounded by water, it is converted back into an island (tagged
with the land tag) and a warning message is issued.
Tested with the GB map,
Hi Mark,
I tested both without and with --generate-sea=polygons. Sorry,
I did not run --generate-sea=polygons without your patch. With
generate-sea, I found some anti-treasure like the following.
2010/01/26 22:41:52 WARNING (Osm5XmlHandler): Way null
Hi Lambertus,
On Sat, Jan 23, 2010 at 06:11:56PM +0100, Lambertus wrote:
There are a few tiles that fail to render due to 'Bad file format:
63240029.osm.gz' on every update and I've tracked it down to Mkgmap
complaining about a '' character in the role id of a way in a relation.
Example:
Hi Steve, Felix,
On Fri, Jan 22, 2010 at 04:10:54PM +, Steve Ratcliffe wrote:
So what I will do is revert 1498 on trunk and then put the patch in to
the style branch instead. Is that OK? Once the style branch is
merged and settled you should never have to spend so much time
changing
Hi WanMil,
On Fri, Jan 22, 2010 at 12:19:31AM +0100, WanMil wrote:
Attached patch can be summarized very easy:
* Major speedup for mp code
Please test and commit if no problems arise.
Sorry for nitpicking, but could you please fix a few formatting issues
and comments in the patch? Some
The Nuvi user whom I have mentioned before reported that the routing between
Tapiola, Espoo and Töölö, Helsinki was broken for some weeks until it
started working again with yesterday's map.
The only explanation that I can think of is that I shrunk the map tile
to get rid of the TRE header
Hi Felix,
On Thu, Jan 21, 2010 at 02:31:19AM +0100, Felix Hartmann wrote:
My main concern is that Garmin map publishers (like Onroute) use large
parts of my style-file to have better autorouting and produce closed
source commercial maps. They currently do many things wrong (even though
On Tue, Jan 19, 2010 at 10:20:38AM +, Steve Ratcliffe wrote:
Hi Marko
I still can't view the gmapsupp.img because of a NullPointerException:
I can only think that this is due to an img that has failed to build
properly. I saw one case of this was using the command line option
On Tue, Jan 19, 2010 at 12:42:46PM +0200, Marko Mäkelä wrote:
The r1501 fixed it. But why was no TRE section generated by mkgmap
in the first place? Will it do any harm if it is missing? Or was the
TRE section generated in the wrong place? I am using --max-jobs on a
dual core processor. I
On Tue, Jan 19, 2010 at 03:10:12AM -0800, Fabrizio Lorenzini wrote:
I am trying to use the relations to build a simple map (to use over my
existing OSM map produced with mkgmap too) with only mtb routes.
I've tried with a simple relations file like this:
type=route route=mtb { apply { set
Hi Steve,
I am attempting to reproduce from your script.
OK I have reproduced the problem. It appears that the directory withing
the IMG is empty and yet the file is quite large, so something is very
wrong.
Can you add some diagnostics for this case? Preferrably near the place
where
Hi Felix, Fabrizio,
On Tue, Jan 19, 2010 at 12:33:28PM +0100, Felix Hartmann wrote:
Running mkgmap with these two files against an Italy extract from
geofabrik.de, I am only able to see ways wich have route=mtb in herself.
All ways wich belongs to a relations are simply ignored.
On Tue, Jan 19, 2010 at 05:36:44AM -0800, Fabrizio Lorenzini wrote:
I'd like to have different maps for mtb routes, hiking routes, cycleway
routes and so on, in order to enable/disable it on my Oregon when I need it.
I have exactly the same goal, but it will take a few weeks until
I can create
Hi WanMil,
On Tue, Jan 19, 2010 at 07:04:54PM +0100, WanMil wrote:
This seems to be another bogus warning:
2010/01/19 09:26:47 WARNING (MultiPolygonRelation): Cannot join the
following ways to closed polygons. MP-Relation
http://www.openstreetmap.org/browse/relation/302408
I did
Hi Fabrizio,
On Tue, Jan 19, 2010 at 06:59:59AM -0800, Fabrizio Lorenzini wrote:
If I were you, I would use JOSM to download and save a small area that
contains a route. (Or you can define a bogus route relation on your
home street and not download it, just save it to a file that you would
Hi Felix, all,
On Wed, Jan 20, 2010 at 01:18:18AM +0100, Felix Hartmann wrote:
I am going to publish my style-file (and dual license the rest like
typfiles), but I would like that
a) any works that build upon it, have to give attribution to openmtbmap.org
b) any maps generated by using the
Hi Steve,
I see. I guess that only the first matching [] rule will be run
and that any {set} or {add} rules will not affect further tests.
There is a 'continue' keyword that allows further matches to take
place.
The 'continue' keyword is for the [] action, right? And the further
On Mon, Jan 18, 2010 at 09:10:49AM +, Steve Ratcliffe wrote:
On 18/01/10 08:13, svn commit wrote:
RuleFileReader.optimiseAndSaveBinaryOp(): Try to be symmetric.
optimiseAndSaveAndOr(): Refactored from optimiseAndSaveBinaryOp().
So you are trying to transform
a=b (c=d|e=f)
to
I think I reported something similar a while back, and it was fixed by
reverting some revision. This one is somewhat different, because the
crash occurs with Geofabrik's finland.osm.bz2 from Jan 18 (today), but
Jan 13 is fine.
I am using mkgmap r1490 and splitter r103.
Exception in thread main
Hi Steve,
There are lots more things that do not work, here are a few that I've
just tried out:
1. a~b# doesn't work
2. a~b c=d # works
3. a~b c~d e=f# doesn't work.
4. (a~b | c~d) e=f # works
5a (a~b | c~d) e=f g=h # doesn't work
5b ((a~b | c~d) e=f) g=h #
Hi Felix,
On Mon, Jan 18, 2010 at 02:19:45PM +0100, Felix Hartmann wrote:
Actually I found two ways how to make it work. Sometimes the mkgmap
style-file code allows so many nice workarounds. :-)
*a)* the odd way
rcn_ref=* rcn_ref=10{ name '${rcn_ref}' } [0x01701 resolution 22
Hi Steve,
On Mon, Jan 18, 2010 at 05:09:05PM +, Steve Ratcliffe wrote:
I produced the attached patch which makes all the previous examples
compile (apart from the plain a~b example).
Great! The algorithm looks OK to me.
I have some remarks about it, using stricter type casts, adding
I am getting these for yesterday's finland.osm.bz2 and mkgmap r1499.
I suspect that these are coming from the branches/mp merge:
SEVERE (MultiPolygonRelation): Multipolygon
http://www.openstreetmap.org/browse/relation/5828 contains intersected ways
This relation or the containing points have
Hi Felix,
Thank you for testing my patch. In any case, I will try to figure out
what caused the size difference for me. Even if the patch does not seem
to bring much CPU-wise, the compact notation could be useful in some cases.
But as your example shows, the downside of the compactness would be
Hi Greg,
Last night, I wrote:
We could do that, but I just got another idea: I will create a simple
TYP file with http://ati.land.cz/gps/typdecomp/ and try to decompile
it by hand into source file(s) that would be compiled with GNU Assembler
to the TYP file. That should be enough for my
On Sun, Jan 17, 2010 at 04:11:51PM +0100, Felix Hartmann wrote:
Something fundamentally fucks up in with your patch or there is again
some typo that I made?
Something fundamental seems to be wrong. I did not look how the matching
is actually done.
Marko
Hi Steve,
It doesn't work like that, so we don't do multiple hash lookups and
equality comparisons for each rule.
We go through the tags and look each one up, based
on an index consisting of the tag and value. So all rules that could
be matched by say natural=mud are indexed by the string
Hi Steve,
There is code for generating TYP files under the ...imgfmt.app.typ
package, and I may have some more code from Thomas that what is checked
in which I could send you if you want to follow that route.
Thanks, it could be a good long-term solution.
In any case, I will first have to
Hi Steve,
If there are multiple rules with the first term natural=mud then they
are put into a list in the order that they occur in the file. They are
then evaluated in order until one matches. Only the conditions after
natural=mud are run, eg for the rules:
natural=mud colour=brown
Steve,
This patch seems to work for me, but as I am not familiar with the
pattern matching in the mkgmap style engine, I would like to ask
for review and approval.
Best regards,
Marko
Index: src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java
Hi Felix,
On Sat, Jan 16, 2010 at 09:02:05PM +0100, Felix Hartmann wrote:
On 16.01.2010 20:59, Marko Mäkelä wrote:
+natural ~ 'wetland\|marsh\|mud' [0x51 resolution 20]
Is there a performance increase (or maybe memory usage decrease) vs:
natural=wetland | natural=marsh | natural
On Sat, Jan 16, 2010 at 07:37:01PM +0100, Felix Hartmann wrote:
Hi, would it be possible to integrate an overlays file for POIs? The
current overlays file (inside the style-file) only works for polylines.
I would like to do the same for POIs. (I don't think it is needed for
polygons, but
On Fri, Jan 15, 2010 at 10:23:51PM +0100, Felix Hartmann wrote:
Do you know the author of maptk? Could he be convinced to release the
source code of the TYP compiler under the GPL? If not, how much and how
often has the PRJ file format been changed in the past? In other words,
would it
On Fri, Jan 15, 2010 at 02:44:10PM +, svn commit wrote:
Polygons that are recognised/fabricated by the sea generation code should
not have any tags that could generate a line as they would stop the polygon
from being generated. An obvious candidate is the boundary tag which will
often be
Hi Mark,
Will this discard boundary=administrative from islands completely,
or only from mkgmap polygon objects, and keep the tags on line objects?
The coastlines of large islands sometimes are administrative boundaries,
and these are translated by the default style.
Hmm, on
Hi Felix, all,
On Thu, Jan 14, 2010 at 11:39:51PM +0100, Felix Hartmann wrote:
I use maptk: http://maptk.dnsalias.com/
it is freeware but not OS - it is however available for Python, Linux
and Windows.
Thank you for the hint. I downloaded MapTk 2.7 Python.zip. The software
is in .pyc files
On Fri, Jan 15, 2010 at 06:23:51PM +0100, WanMil wrote:
The attached patch changes the OSM-URL (toOSMURL()) so that a small
needle is shown at the location of the Coord.
The current OSMUrl has no clear indication of the real location of the
Coord.
Thanks, I committed this (without adding
On Fri, Jan 15, 2010 at 09:40:52PM +0100, Felix Hartmann wrote:
maptk only supports 2 colors (as no nightmode support is included, 4
colors mean 2 colors daymode and 2 colors in nightmode). It could well
be that maptk did some changes to the colour palette. I think it tries
to make colors
For what it is worth, my 2 cents:
On Thu, Jan 14, 2010 at 10:36:54AM +, Chris Miller wrote:
1) Nodes and ways get intermingled in the output OSM file. I don't think
this is a problem at all since there still won't be any forward references
from eg ways to nodes, but currently the
Hi Chris,
I hadn't realised that forward and even circular references were common
though so thanks for pointing that out, I'll need to bear that in mind
when I add support for it.
I don't know about circular references in practice. I ran into the forward
references when learning about
This may be slightly off-topic, I think that it could be useful to have
a repository of TYP files and associated style definitions. For example,
a TYP file would be necessary to define a custom line style for displaying
bus route information on a separate map layer.
It seems that
Hi Charlie,
I was wondering if it would be worthwhile to split all barriers
(fences, gates, bollards, whatever) and traffic_calming to a separate
layer? These objects are not usually searched for or routed to, and
they are not relevant for navigation much of the time.
To an extent, I
On Wed, Jan 13, 2010 at 05:00:36PM +0100, Torsten Leistikow wrote:
I do not think, that a set of such scripts should be included into mkgmap.
It is too much overhead for the different style developer to keep their
scripts in the mkgmap repository up to date.
You may be right. I was about to
On Tue, Jan 12, 2010 at 09:08:16PM +0100, Clinton Gladstone wrote:
I noticed that JOSM now has amenity=bar in the presets list. Also OSMdoc
indicates that there are 2096 nodes with this tag.
Would it make sense to add the following to the points style file:
amenity=bar [0x2d02 resolution
Some time ago, I faced some opposition against adding this to
styles/default/points:
+traffic_calming=* [0x6614 resolution 21]
I was wondering if it would be worthwhile to split all barriers
(fences, gates, bollards, whatever) and traffic_calming to a separate
layer? These objects are not
On Fri, Jan 08, 2010 at 10:41:41PM +, Mark Burton wrote:
Another question: Is there a possibility to see the changes in the current
mkgmap version?
I don't know about accessing the history using SVN but you can
browse the changes at the GIT mirror:
http://github.com/burto/mkgmap
On Tue, Jan 05, 2010 at 08:52:59PM +, teamc...@mkgmap.org.uk wrote:
Build mkgmap::trunk build #1469-710 failed (tests failed: 3, passed: 106)
Agent: Default agent
Build results:
http://teamcity.mkgmap.org.uk/viewLog.html?buildId=2198buildTypeId=bt2
Failed Tests Summary:
Failed tests
Hi Felix,
Actually as you're working on it. Is there an easy way to specify
priority of apply for several routes?
I wish there were, because I would like borders to be named in a logical
order (biggest entity first if a boundary line belongs to multiple
admin_levels).
I suppose that there
On Tue, Jan 05, 2010 at 12:28:42AM +0100, Felix Hartmann wrote:
Either 1465 or 1466 are incompatible to the the mp branch (I copied
in the multypolygons.relation file from mp brunch to trunk...)
multipolygon outer will not be displayed 3km or closer in Mapsource (but
5km and up
On Mon, Jan 04, 2010 at 01:04:02PM +, char...@cferrero.net wrote:
Quoting svn commit s...@mkgmap.org.uk:
Version 1458 was commited by marko on 2010-01-04 13:01:28 +
(Mon, 04 Jan 2010)
Enable some POIs in the default style:
amenity=car_club, natural=stream,
shop=boat,
I figured out that mkgmap does already support nested relations, but it
is not working for me. The attached patch attempts to copy the route name
to the members of member relations. This is the relation in question:
relation id='155054' timestamp='2010-01-03T22:13:56Z' uid='93285'
On Mon, Jan 04, 2010 at 03:07:30PM +, Steve Ratcliffe wrote:
On 04/01/10 14:52, Marko Mäkelä wrote:
The .img file comes from mkgmap. What is the TRE section good for, and
how could I ask mkgmap to generate it? I am not using mkgmap --index,
because I target the device, not MapSource
701 - 800 of 935 matches
Mail list logo
