Moin,
Chris66 schrieb am 05.10.2012 10:22:
When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is
evaluating the first way behind all the _link ways.
...
So the idea is a new mkgmap option --process-destination
which does following pre-processing:
For all _link ways which have a
Greg Troxel schrieb am 27.11.2011 17:12:
I still don't understand why it would make sense to make a POI
per node. What I'm getting at is that perhaps the line2poi code should
somehow default to making only one synthetic point POI.
Below is an example from my points-style, where I generate
Moin,
Felix Hartmann schrieb am 17.11.2011 19:35:
There are only very very few cases where I
can see this option having any sense for me, so I would have to use
quite a lot of
mkgmap:line2poi!=true
statements.
Actually you do not need so many statements like this, since you can
Moin,
I want to do some modifications of the tag-values via the style file. I know
this has been a topic here before, but I can not find the neccessary hints right
know.
- How can I check the first character of the value in a style file? (I want to
detect whether the first character is a minus
Moin,
Marko Mäkelä schrieb am 03.11.2011 19:37:
I hope that this helps.
Thanks, with your help I was at least able to filter out the non-numeric values
by using
incline ~ '^-?[0-9]*.'
instead of
inlcine=*
I did not succeed in removing the minus sign from the out put (since the
direction of the
Moin,
WanMil schrieb am 31.10.2011 21:35:
I have modified the patch by the following things:
1. The relation style is now applied before the POIs are added
Today I had the idea of solving the problem the other way around: Add the
artificially created POIs as members to the relation.
But doing
Moin,
I tried the patch and I think the add-pois-to-lines option is quite usefull.
Although I have some issues with the actual implementation.
1. Tags originating from the line are correctly transfered to the points (e.g.
incline=* on the highway can be used to generate symbols at the highway
Moin,
WanMil schrieb am 30.10.2011 14:10:
The relation style is applied after the pois-to-lines. Maybe this could
be changed but I don't know about side effects.
That is bad news, because using the add-pois-to-line options for marking hiking
routes is one of the uses I had in mind.
It is
Moin,
Chris66 schrieb am 28.10.2011 17:52:
So it works.
Can you please provide your mkgmap.jar file? I do not have a development
environment for mkgmap at the moment but would like to try out the patch.
Gruss
Torsten
___
mkgmap-dev mailing list
Moin,
I really would like to have an add-pois-to-lines feature.
Henning Scholland schrieb am 26.10.2011 00:24:
This would also be a great feature to show route-signs (hiking, cycling
etc.)
But it would be overkill, to create such a node for each way.
Actually it wouldn't be enough, to
WanMil schrieb am 27.09.2011 23:28:
Do I understand you correct?: The polygons style should be used for
polygons created by mp processing but only one POI should be created for
the whole multipolygon and not one for each mp created polygon.
I think, we are in agreement here:
1. A
WanMil schrieb am 27.09.2011 19:27:
Maybe it's not be too difficult to fix that. Here is my idea:
Just before the style conversion one point for each polygon is added
with a copy of all tags plus mkgmap:poly2poi=true. Polygons contained in
or created by a multipolygon are excluded but
David schrieb am 01.08.2011 19:20:
My first idea was an error in OSM file, but I cannot find bad data.
You could try to put the OSM-ID into the name of the object (via the
style-file). As a result on your Garmin you would be able to figure out, which
OSM object is the source for your trouble.
Moin,
Rich schrieb am 24.07.2011 18:58:
what is the current suggested use of add-pois-to-areas - have any
changes like
http://gis.638310.n2.nabble.com/POIs-for-areas-td6043656.html been
introduced recently ?
This modification was never merged into the trunk, because it is not backward
Felix Hartmann schrieb am 14.07.2011 12:16:
Is the ramp two sections??
For me (with my style), ramps do work with the name of the next street
segment behind. Not sure what happens if the ramp is several sections (I
suppose the first real street behind should be used).
0x09 needs to be
Charlie Ferrero schrieb am 03.07.2011 08:55:
In Mapsource (6.16.3) these labels render differently (see attached).
Building 1 renders as Khalidiya Palace Tower a
Building 2 label renders as Khalidiya Palace Tower C
Is this a bug in mkgmap or a bug in Mapsource?
I think, this is a Garmin
MarkS schrieb am 03.05.2011 22:58:
Would something like this work?
highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue]
highway=motorway oneway=yes [0x10f01 level 6]
highway=motorway oneway!=yes [0x10f02 level 6]
Then style 0x01 with no style (so nothing is drawn) -
Charlie Ferrero schrieb am 28.04.2011 09:46:
Why is the warning correct? The wiki says that a boundary multipolygon
can contain a node tagged admin_centre. Isn't this mkgmap warning a
false positive?
Actually this is depending on the type of the relation. With type=multipolygon
there
Thorsten Kukuk schrieb am 03.05.2011 20:53:
But with both statements, the arrow is always drawn below the street.
Is it somehow possible to have the arrow on top of the street?
The drawing order of the lines in a single map is not really understood and can
not be set via the style file.
For
Felix Hartmann schrieb am 16.04.2011 16:13:
I don't understand for whom this option is usable. If I use a
relations file, then I assume I may not use this option (else
relations won't be processed). And also one will be missing stuff like
boundaries and maybe some forests
My understanding
Moin,
since my GPS-maps rely heavily on multiple layers, there would be some benefit,
if producing of these layer could happen within a single mkgmap run, so that the
common proccesing steps would be executed only once.
Whether this can be achieved, depends on the time of the processing step. I
WanMil schrieb am 17.03.2011 21:12:
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely contained
in the tile data. The polygons are closed automatically but this is only
a good guess in which direction they have
Moin,
I had some trouble getting the search in Mapsource working when building my maps
with r1871. Finally I got it working, but only after removing the
--overview-mapname option. Doers the --index option not work in combination with
--overview-mapname?
Is there any documentation about th enew
Ralf Kleineisel schrieb am 08.03.2011 18:09:
Lines file:
junction=roundabout highway=secondary [0x11f02 road_class=2
road_speed=3 level 4]
Overlays file:
0x11f02: 0x0c, 0x04
Then I created a test typ file with a very broad pink 0x0c just to see
if the two lines are really there. They
Marko Mäkelä schrieb am 03.03.2011 22:54:
Could you elaborate what your patch does? Does it remove the option
add-pois-to-areas altogether? Even though an add_poi action would replace
add-pois-to-areas, I think that we should support both forms for some time.
Sadly this patch disables the
Jeffrey Ollie schrieb am 04.03.2011 16:09:
Whitespace-only changes should be included in a separate patch that
does not change any functionality. That makes it easier to review
changes.
Thanks for the clarification.
Gruss
Torsten
___
mkgmap-dev
Moin,
my mkgmap build process is very shaky, but finally I managed to create a patch
of my changes. Perhaps it is even working?
Gruss
Torsten
Index: src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java
===
---
Marko Mäkelä schrieb am 28.02.2011 13:04:
The wiki http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack says
that leisure=track is to be used on nodes and ways. This hints that you
should add area=yes when you mean an area.
The wiki http://wiki.openstreetmap.org/wiki/Map_Features also
Moin,
Marko Mäkelä schrieb am 27.02.2011 10:32:
I got 2386 additional warnings. Some are for thin man_made=pier that
have been drawn as lines. There is man_made=* in the polygons style
file.
I have not tested the polygonclose_v2.patch but it sounds like it has the
inverse effect of the
WanMil schrieb am 27.02.2011 16:53:
Your example will result in
1. line with 0x01
2. a) nothing more if node1 or node2 is within the tiles bounding box
b) a polygon 0x02 if node1 and node2 is outside or on the tiles
bounding box.
Ok, I will try out r1865 when it is availbale as a
Chris66 schrieb am 22.02.2011 11:05:
Indeed the most MPs are tagged like this:
relation: type=multipolygon
outerway: landuse=forest (example)
innerway: no-tags (or tags for inner area).
The forest is of course only the area between inner and outer.
This is one of the accepted taggings
Jean-Marc Meessen schrieb am 20.02.2011 14:24:
* Am I using the latest version of the PBF splitter branch (I also
tried the compiled r161-3) ?
* Is this a known problem ?
* Is something wrong with my parameters ?
I was using a windows 7 PC for this.
Thanks in advance
Jean-Marc Meessen schrieb am 20.02.2011 14:53:
The file I am trying to split is fairly small, Torsten. It is about 30kb
large (while the european data is 5gb). The splitter version is from end
january.
Isn't the extract too small and thus the Osmosis extract went wrong ? I
am extracting
WanMil schrieb am 08.01.2011 11:44:
I have attached that patch to limit polygon creation to closed ways.
It's untested and I assume there are some unwanted effects at tile
borders. Please check and if you (and others) find it usefull it can be
committed.
Did anybody else try this patch? I
Ben Konrath schrieb am 03.02.2011 12:51:
That's a bug. If I recall correctly, the POI should only be added if
there's no POI with the same name already in the polygon. I should
really fix this. Thanks for pointing it out.
No, in the OSM data is only a polygon, and AFTER the POI is added to the
Moin,
Henning Scholland schrieb am 31.01.2011 21:41:
Why you
would like to have a POI for an object taged as node and not for a
similar POI taged as polygon?
In OSM some objets can be mapped in OSM as a node or as an area, depending on
the availability of the source data. If they are mapped
Marko Mäkelä schrieb am 31.01.2011 20:16:
On a related note, I believe that an alternative to add-pois-to-areas
should be implemented, by introducing an add_poi action in the polygons
style file. In that way, one could flexibly choose which polygons
deserve a POI.
I just started using
dom Team OiD schrieb am 28.01.2011 19:24:
Is also the big file problem fixed?
I think about the europe file splitting. Is this problem solved?
Yes, that is the new of the new version.
Gruss
Torsten
___
mkgmap-dev mailing list
Johannes Formann schrieb am 13.01.2011 22:32:
The generate_ways_from_relations.patch is used to give cycleroutes good
attributes (road_class, speed), so they were preferred over normal roads,
independed on which roads they actually run. (But dependent on the network
different, rcn other
Moin,
I think the problem is not the multipolygon, but that some of the outer ways are
tagged with surface=sand. These tags are not considered for the multipolygon,
but for these ways mkgmap creates single surface=sand polygons.
But if you change your polygon style from
surface=sand [0x1b
Valentijn Sessink schrieb am 25.12.2010 11:03:
I remember having this problem with an older version of Java. See the
mailing list messages Map missing from r1363++ and weird: file
missing when # of files 10?, november 2009.
Java version 1.6.0_16 had this problem, java version 1.6.0_17 did
Valentijn Sessink schrieb am 25.12.2010 11:03:
Java version 1.6.0_16 had this problem, java version 1.6.0_17 did
not have it.
Does that help?
An update of my Java version solved the problem.
Thanks!
gruss
Torsten
___
mkgmap-dev mailing list
Maks Vasilev schrieb am 08.12.2010 14:25:
How to increase precision of node coordinates?
In general there is no way to increase the precision of node coordinates.
The only cause for problems is sometimes the remove-short-arcs option. I donÄt
know whether there is a default value, so you could
aighes schrieb am 06.12.2010 19:33:
I've the same problem with todays europe.osm.pbf. Extract of 02.12. works
fine (was the last I used).
Me too.
The resulting map contains only POIs and no lines or polygons.
Gruss
Torsten
___
mkgmap-dev mailing
Moin,
I tried some changes in my map generation, but I was not able to clearly
identify the problem:
- If I reduce the number of map tiles in my arguments file, all tiles are
included in the tdb-file. I have never seen it go wrong with less than 8 tiles,
I have never seen it working with more
Moin,
I am creatig my maps with mkgmam-r1733 with the following command:
java -jar -Xmx8096M ../../mkgmap-r1733/mkgmap.jar
--style-file=../../styles/topo_v005 --remove-short-arcs=5
--generate-sea=extend-sea-sectors --family-id=62 --country-name=Deutschland
--country-abbr=D --family-name=Topo
Felix Hartmann schrieb am 17.11.2010 22:30:
Below is the outcome I want to have for tracktype=1 and respectively
tracktype=5
if tracktypeadded=yes THEN build 0x07 (no matter if tracktype exists,
and no matter which value it has).
if tracktype=5 THEN do build 0x07 (if tracktype does not
Felix Hartmann schrieb am 18.11.2010 17:18:
table should look like this for tracktype!4
tracktype -build 0x07
not set yes
1 no
1 no
2 no
3 no
4 no
5 yes
5yes
any
maning sambale schrieb am 17.11.2010 14:36:
AFAIK, the correct way of tagging is:
way 1 - amenity=townhall
way 2 - no tag
relation
type=multipolygon
way 1 = outer
way 2 = inner
I'll check other data to verify.
This one of the possible solutions.
Also ok would be
way 1 - no tag
way
aighes schrieb am 17.11.2010 20:21:
instead of ! you could use = or =. I don't know if there is a difference.
For example:
( tracktype=5 | tracktypeadded=yes )
I think he wants to have
(tracktype!=* | tracktype5)
The difference is, when there is no tracktype defined at all.
Gruss
Torsten
maning sambale schrieb am 26.10.2010 10:53:
The default style treats motorway_link as oneway by default. I've seen
some cases (in the Philippines) where this isn't so. Is it the same
case for other countries? If so, I propose we modify the default
style. Or, any suggestions to modify the
Steve Ratcliffe schrieb am 12.10.2010 00:16:
if anyone has any ideas please post.
As a user I would like to have an action command in the polygon (and also in the
lines) style rules for generating a POI for a specific area (and also for a
specific line). Actually I would like to have multiple
Josef Latt schrieb am 07.10.2010 11:23:
one of the river (tracks Rhein) where the boundaries, shown as river,
starts has two ways. One with tag boundary and waterway=river, the other
only with waterway=river.
I don't understand your problem. When the way ist tagged as boundary and as
river at
Josef Latt schrieb am 07.10.2010 20:03:
That means that a tagging like this is false?
...
tag k=boundary v=administrative/
...
tag k=waterway v=river/
If the river itself is the boundary, then this tagging is ok.
But in such a case, you can't complain, that the boundary is shown as
char...@cferrero.net schrieb am 27.09.2010 15:20:
As an example take a nature reserve consisting of a wood with a lake inside.
This migth be mapped with two polygons and a relation:
polygon A: leisure=nature_reserve (the complete area)
polygon B: natural=water (only the inner area)
char...@cferrero.net schrieb am 27.09.2010 16:49:
OK, but in practical terms if mkgmap generated a nature reserve
polygon, a wood multipolygon and an inner water polygon, wouldn't the
visible results be undefined? In other words, you could end up with
either:
a) Wood multipolygon
WanMil schrieb am 24.09.2010 19:29:
My understanding of the multipolygons is, that the tags may EITHER be
in the
relation OR on the outer polygons. So the outerpoylgons are only to be
used,
when there are no tags on the relation.
If the relation itself is tagged and there is a tag on the
WanMil schrieb am 20.09.2010 20:44:
Attached patch performs only the line styles on unclosed ways (the patch
is untested!!).
I tried your patch and I didn't notice any unwanted side effects.
Since this is quite a change from the previous behaviour, perhaps it would be a
good idea to control
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the
relevant polygon tags or if the tagging should be taken from the outer
ways. For this purpose a list of known polygon tags is used and up to
now leisure is not in this list.
My understanding of the
Scott Crosby schrieb am 22.09.2010 20:42:
My advice is to wait a few weeks for new releases to come out.
For a production version: yes, sure.
But this is the development list of mkgmap, so it is all about trying out new
stuff and getting it fixed. This is how the new releases in a few weeks are
WanMil schrieb am 21.09.2010 23:30:
This has been fixed with r1700 so the problem should not
exist any more.
I can confirm, that r1701 does not crash any more.
Thanks for the fast fix.
Gruss
Torsten
___
mkgmap-dev mailing list
WanMil schrieb am 20.09.2010 20:37:
But I am not sure in what situations the bug happens. Could you do me a
favour and run mkgmap with the following log.properties file?
Is this problem already solved with r1700?
Otherwise I have to admit, that I do not know how to run mkgmap with a
char...@cferrero.net schrieb am 20.09.2010 07:52:
Personally, I would love it if some logic could be added to mkgmap for
it to be able to detect whether something is a closed polygon or not,
which would make it much more robust in these instances.
I would also like to see such a feature,
Moin,
I have a problem with mkgmap version r1699: it crashes while generating my maps.
With r1673 everything was ok.
It does not seem to be related to the style, I tried different layers of my maps
and all are crashing.
I use the following mkgmap command line and get this error message:
java
Marko Mäkelä schrieb am 10.09.2010 22:55:
Yes, apply role=value (role ~ 'regexp' would be nicer, but not
implemented). It would also be nice to check for the type of the member
(node, way, relation), but there is no syntax for that.
See
Hallo,
is there any way to use the tag values of the members of a relation within the
apply command in the relations style file?
With
apply {set Member_Tag_Value=${Relation_Tag_Value}}
I can set the tag value of the relation to all its members.
Instead of just setting the tag in the member,
Apollinaris Schoell schrieb am 10.09.2010 18:41:
long time ago I have done it with a temporary tag name in the relations file.
and then in the line style test for existence of the temporary tag and
combine with the tag values from the lines the only change you need is to
test the existence of
Marko Mäkelä schrieb am 10.09.2010 22:12:
I implemented the $(variable_name) syntax some time ago, to get bus
route relations translated properly. An excerpt from --style=routes:
[relations file]
type=route ... {
apply { set mkgmap:route='$(mkgmap:route),${ref}' | '${ref}' }
}
[lines
Paul Ortyl schrieb am 09.08.2010 18:00:
Should I expect, that routing in MapSource should work?
Yes.
I do not use the default style, but in general routing does work (atleast when
the routes are not to long).
Gruss
Torsten
___
mkgmap-dev mailing list
Moin,
NopMap schrieb am 21.05.2010 07:57:
For three weeks I have been unable to grab a planetfile with correct
coastline for central europe - they are broken at about the same speed we
can fix them. So even though I was able to build a really nice map a while
ago, all update attempts were
Chris-Hein Lunkhusen schrieb am 28.03.2010 14:22:
I don't know how the MP code works, but it should not copy tags
like boundary=* to the multipolygon cutting lines.
They should stop putting the boundaries into multipolygons.
The problem is, that the boundaries are tagged as areas (thats the
WanMil schrieb am 28.03.2010 21:43:
The patch excludes the boundary relations from the multipolygon
processing. This can be changed with the new option
--process-boundary-relations.
This might solve the actual problem, but I think it is a dirty hack. When we
have the next tag with such a
Chris-Hein Lunkhusen schrieb am 27.03.2010 20:44:
I see in Mapsource many boundary lines which are not existing in the OSM
data. See attached screen shot.
Are these lines coming from the multipolygon processing?
Probably yes.
On 17.02. WanMil provided a patch, that allowed the distinction
Steve Ratcliffe schrieb am 25.03.2010 00:49:
The difference is down to the 'name' command being like 'add' and not
like 'set'. If you use add instead of set, then it behaves
consistently with the way that name behaves.
Ah, thanks for the explanation.
Actually where is the best
Steve Ratcliffe schrieb am 25.03.2010 18:24:
The best place is on the wiki at:
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
On the whole it doesn't include things that were not added by me
though.
Obviously there are some features missing. At least now I know, where I should
Toby Speight schrieb am 23.03.2010 11:03:
That's a bit more difficult for me - I'd have to generate it on the
fly, as I don't know how many tiles the splitter is going to throw out.
Unless there's a way around that?
If you are always splitting the same areas, you can use an area list as
Moin,
I want to create two symbols for a single element (tagged with key=value), and
both symbols shall have different name (alpha and bravo).
If my points style looks like the following
key=value {name 'alpha'} [0x6005 resolution 20 continue with_actions]
key=value {name 'bravo'}
Jeffrey Ollie schrieb am 02.03.2010 21:07:
I've listened to that argument for a while and I'm tired of it.
And I have tried to fight this anarchy and I got tired of it. So I accepted it
as a fact and became much more relaxed and satisfied with OSM :-)
Gruss
Torsten
Daniela Duerbeck schrieb am 03.03.2010 01:05:
What if you add a list where one can add explicitely which POIs should
be generated (supermarket, shop, restaurant, etc.)?
I would like to have some action commands for the lines and polygons style
files, where you could specify, that an extra
WanMil schrieb am 02.03.2010 18:48:
The patch supports the complete multipolygon specification. And
additionally it is tolerant towards incorrect (but reasonable)
multipolygons.
So why should mkgmap be restrictive if it doesn't need to?
Since there is not really a specification for the OSM
Moin,
I have a problem with POIs, which have an ref-tag (using mkgmap-r1586).
First of all, if the POI does not have a name, then the ref-tag is displayed in
the map. In my lines file, I have specially a rule for adding the ref-tag to the
name, so I am a little bit surprised, that this is
Moin,
I tried a slightly modified patch provided by WanMil, where also mkgmap:mp_*=no
tags are added:
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 and mkgmap:mp_created=no.
Mark Burton schrieb am 20.02.2010 14:02:
motor_vehicle is not understood by mkgmap - how about:
{set access=no; set foot=yes}
Ah, that does the trick. Thanks!
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Moin,
Minko schrieb am 17.02.2010 16:05:
I don't know if this already has been discussed, but some combinations of TYP
file and overlays wont work in Mapsource.
I don't know, whether they are not working, or whether you are expecing too
much.
I didn't follow the discussion, when the overlay
Felix Hartmann schrieb am 14.02.2010 21:10:
That is a bug in Mapsource and won't get solved. Use Mapsource 6.13.6
(for x64 systems) or Mapsource 6.13.7 for x32 system.
This might help, I am using a 6.11 version of Mapsource. Unfortunately my Nuevi
displays it in the same way
Gruss
Torsten
Mark Burton schrieb am 14.02.2010 23:15:
How about: the RHS of the dent is S of the junction with Bruchweg
because the small footway has been completely removed by the
remove-short-arcs option and so the node at the N end of that footway
has been merged into the node at the S end of the
Mark Burton schrieb am 14.02.2010 20:05:
Yes, as the Garmin map resolution is approx 2.2m, it is understandable
for your road to have those dents.
But the offset of the points look much bigger than 2.2m. And this doesn't
explain, why the north-south ordering of the two points is in JOSM inverse
Dave F. schrieb am 06.02.2010 14:01:
I now understand,
I don't think so ;-)
I was under the
impression that a line or polygon in the TYP file could be used to
represent multiple entities in the OSM data, but as the 'type of entity'
name comes from that file, I have to create separate
Steve Ratcliffe schrieb am 30.01.2010 16:13:
No it was just a mistake, I meant it is as if with_actions is always
given - I find the terminology very confusing! I would prefer that
continue not change the normal effect of the actions and there be a
without_actions (or no_carry_forward or
Dave F. schrieb am 24.01.2010 03:47:
Could you explain the continue statement please. I couldn't find
anything on it in the wiki.
For each OSM-object mkgmap normally scans through all rules in your style file
and searches for the rule with the highest priority, i.e. the first rule, that
Felix Hartmann schrieb am 22.01.2010 16:24:
Well until 1497 auxiliary tags worked, now they are broken. I tried it
too. At least if you provide a list of say 15 auxiliary keys. Maybe only
one or two are parsed???
I can't really comment on the latest changes, since my main styles are
Felix Hartmann schrieb am 22.01.2010 16:30:
highway=* copy=99 mtb:scale:uphill!=5 mtb:scale:uphill!=4 {
set dontadd=yes; set taxi=no; set dontadd=oneway; set mkgmap:unpaved=1
}[0x10711 resolution 21 continue with_actions] *output*
Actually, what is the difference between continue
Dave F. schrieb am 22.01.2010 19:03:
In my line style: barrier=wall
In my polygon style:
landuse=farmyard barrier=wall
landuse=farmyard
What do I need to do to get it to render?
I think, right now it is not possible, to get from one garmin element a polygon
as well as a line in the map.
Felix Hartmann schrieb am 21.01.2010 02:31:
I already had quite a few ideas/concepts copied by Garmin map
compilers (e.g. using assymetric transparent lines - which was so
forgotten by Garmin or not intended that they stopped supporting it
until copying many parts for the Garmin
Felix Hartmann schrieb am 21.01.2010 13:51:
This has come since the latest additions to the style-file rules.
And once again I plead for a resurrection of the style branch, so that we can
clean-up the style handling of mkgmap.
Gruss
Torsten
___
Steve Ratcliffe schrieb am 21.01.2010 18:26:
OK I shall start on it very soon.
That's great news for me, Steve. Thanks!
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb am 21.01.2010 19:07:
I wouldn't see (except the strange handling of oneway=reverse - but
maybe there is some error on my side) any strange behaviour with the
trunk currently.
We had quite some topics lately, e.g. that you can not use the same expression
twice, or that
Felix Hartmann schrieb am 18.01.2010 15:42:
The style branch never worked with continue at all, that was the main
problem. At least for me.
I can not confirm this. I am using the style branch combined with the continue
statement.
The style branch is not 100% error free, but in my opinion its
Marko Mäkelä schrieb am 13.01.2010 10:05:
I am not suggesting that mkgmap should generate multi-layered maps by default.
What I would like to have is a simple set of scripts and styles that users
could adapt. Currently, several people have built multi-layered maps and
many have not released
Simon Eugster schrieb am 09.01.2010 19:33:
Any idea? Anyone? :)
Actually I have no idea, why every tile of your map gets its own family-ID. I am
not sure whether this is related to your problem, but typically all maps
belonging to the same mapset (or layer) get all the same family-ID. And
1 - 100 of 131 matches
Mail list logo
