Am 06.04.2013 12:06, schrieb Gerd Petermann:
I think the only improvement is that don't see an empty rectangle in
MapSource or Basecamp
when you open a map for the first time. I don't think that it has any
impact on performance.
The boost could be, that we don't need low levels for the real
Am 06.04.2013 23:00, schrieb Minko:
This is what happens if you use routable lines without a road attribute and
search/route to it:
http://forum.openstreetmap.org/viewtopic.php?pid=207443 post #117
http://forum.openstreetmap.org/viewtopic.php?id=13257p=4 post #79
So maybe it would be useful
Am 10.04.2013 09:06, schrieb Minko:
Hi Wanmil,
I like your first option:
1. Merge the options of the style file at the very beginning of mkgmap
so that all mkgmap sources can uses the same set of options.
A lot of options are related to the style files. When I distribute my styles,
Hithere
If I got it right you can use resolution in style-file and this is
directly used as a garmin-map-level.
OR
I can use level in style-file and this is transferred via --levels=...
to agarmin-map-level.
Is there a reason for having two ways of telling mkgmap on which
Hi,
just another question: Is there a limit of number of levels if I'm using
level? In wiki (
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules#level_.28see_also_resolution.29
) there is only a limited documented with resolution. If the number of
levels is limited, the limited should
Am 11.04.2013 11:53, schrieb Thorsten Kukuk:
On Thu, Apr 11, Henning Scholland wrote:
Hi,
just another question: Is there a limit of number of levels if I'm using
level? In wiki (
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules#level_.28see_also_resolution.29
) there is only
Hi,
mkgmap-TYP compiler throws out an error while compiling a TYP-txt-File
edited with TYPViewer.
[_point]
Type=0x090
SubType=0x00
String1=0x01,
ExtendedLabels=N
DayXpm=1 1 0 1 Colormode=16
;Couleurs 24 bits : pas de palette
#00
#00
;1
[end]
mkgmap doesn't like the line ;Couleurs 24
Am 11.04.2013 15:19, schrieb GerdP:
Hi Thorsten,
it seems that your data has reached a limit in the data structure used in
splitter.
This happens when you have a huge number of consecutive ids.
Can you configure the way how the ids for the points are generated?
A simple change would be to
Am 12.04.2013 00:02, schrieb News:
Like you I think this is a useful option which should stay so I guess
it's down to us to drum up some action on the wiki although I'll confess
that I don't know where the best place to start is as I haven't spent
much time on any wiki let alone one as large
Am 12.04.2013 09:22, schrieb Gerd Petermann:
Statistics for *coords *map:
*Length-1* chunks:*4.580.310*, used Bytes including overhead: 47.376.048
Planet with data of yesterday:
Length-1 chunks: 10.454.925, used Bytes including overhead: 107.695.080
If the rising continueslinear, the limit
Hi Gerd,
my value for max-nodes is also 160.
Henning
Am 12.04.2013 09:36, schrieb Gerd Petermann:
Hi Henning,
that is more than expected. What value do you use for max-nodes? I
used the default: 160.
Besides that I just remember that this problem is also related to the
max-areas
Hi Gerd,
see: http://www.aighes.de/data/splitter.log
If you also need areas.list: http://www.aighes.de/data/areas.list
Henning
Am 12.04.2013 09:50, schrieb Gerd Petermann:
Hi Henning,
please post a link to your splitter log. I want to run splitter with
the same parms and the old planet to
Am 12.04.2013 10:12, schrieb Minko:
BTW IJ is rendered as Ij
As I remember correct, this is a typical Garmin thing. Each word starts
with one capital letter.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 12.04.2013 10:52, schrieb GerdP:
Hi Henning,
yes, whole planet, and I use keep-complete=true, overlap=0 and
stop-after=gen-problem-list because that is enough to get the info.
Gerd
With these parameters and splitting the complete planet I got the
following values:
Length-1 chunks:
Hi Gerd,
I gave it a try, but it failed. The only output I got was:
SparseLong2ShortMapInline: Allocating three-tier structure to save area
info (HashMap-vector-chunkvector)
Length-1 chunks: 93.749.999, used Bytes including overhead: 962.665.848
Length-2 chunks: 0, used Bytes including
Am 13.04.2013 15:36, schrieb GerdP:
Hi Henning,
yes, with large input file the difference is relative small. You may see
problems when you
run a small machine (e.g. a netbook), because then the additional 180MB are
more important.
Maybe you can implement a automatic switch between the two
Hi WanMil,
in general it would be great to have a style-feature in relationsfile to
create a tag based on the rule of the relationmember.
Like:
type=route route=bicyle { apply_to:role { set foo=bar } }
___
mkgmap-dev mailing list
Am 18.04.2013 20:15, schrieb WanMil:
Hi Henning,
that's already possible:
type=route route=bicyle { apply role=forward { set foo=bar } }
Oh...I missed it. But then it shouldn't be necessary to use special
code, because you can manage it via style, or am I wrong?
Henning
Am 18.04.2013 22:30, schrieb WanMil:
Am 18.04.2013 20:15, schrieb WanMil:
Hi Henning,
that's already possible:
type=route route=bicyle { apply role=forward { set foo=bar } }
Oh...I missed it. But then it shouldn't be necessary to use special
code, because you can manage it via style, or
Am 22.04.2013 20:37, schrieb WanMil:
Can you implement these rules?
It should be in relation-file:
type=destination_sign { apply role=to { set
foobar:destination=='$(foobar:destination),${destination}' |
'${destination}' } }
Now every to-way is tagged with destination-Tags of all relations
Hi,
is this option in general necessary? I think it could be quiet simple be
solved in style-file.
name:en=* { set foobar:name='${name:en}' }
int_name=* foobar:name!=* { set foobar:name='${int_name}' }
foobar:name=* {set name='${foobar:name}' ; delete foobar:name }
would be equal to:
Am 23.04.2013 14:28, schrieb GerdP:
Hi Henning,
I think it is needed.
The values are e.g. used in the LocationHook, which is executed before the
style rules.
Ok, sounds logical.
Maybe a filter-style-file would be a great solution for all such
problems (also for process-destination).
This
Hi Gerd,
my intention was a little bit different. I explain it a little bit more.
For example the LocationHook needs a name of the boundary-relation. So
actually the data is read and name-tag-list filters data and picks out
the correct name-tag.
My proposal is, that there is a variable filter
Am 26.04.2013 11:14, schrieb svn commit:
- print all warnings to stdout (one was printed to stderr by mistake)
Hi Gerd,
would it be possible to print out also the osm-way-id?
I get actually some reports, but my style is ok, so I would like to
investigate why these reports occur.
Henning
Hi Gerd
Am 27.04.2013 21:07, schrieb GerdP:
Hi Henning,
please try r2580 first if you use an overlays file.
I tried it with r2580 with same result.
SEVERE (MapBuilder): 1042.o5m: Non-routable way with routable type
0x0e is used for a routable map. This leads to routing errors. Try
Am 28.04.2013 13:24, schrieb GerdP:
Hi Henning,
what does --check-styles show?
java -jar -Xmx6000M ./bin/mkgmap.jar --style-file=./resources/style_rrk
--check-styles
Time started: Sun Apr 28 13:35:21 CEST 2013
Found one style in ./resources/style_rrk
finished check-styles
Time finished: Sun
Am 28.04.2013 13:18, schrieb Bernd Weigelt:
is it possible to reduce output of splitter on stdout?
Most infos are IMHO useless for DAUs like me and shut be on stderr or
in a logfile like mkgmap's
Hi Bernd,
I'm sending stdout to a file lika splitter.log. Terminal stays clean and
in case of an
Hi Gerd
SEVERE (MapBuilder): 1042.o5m: Non-routable way with routable type 0x0e
starting at http://www.openstreetmap.org/?mlat=46.15820mlon=11.94077zoom=17
is used for a routable map. This leads to routing errors. Try --check-styles to
check the style.
is caused by way:210139111 and
Hi Gerd,
I haven't tested with your patch, but I played a little bit with my style.
I reduced lines-style to
(highway=path | highway=track) [0x01 road_class=1 road_speed=1 level 3]
and some more Tiles are effected. This is ok, because now ways which are
unsuitable for bicycle are also used for
Hi Gerd,
I got no more warnings to stderr with this version.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I got no more warnings about routing-problems to stderr with this
version. Thanks!
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 06.05.2013 10:12, schrieb Minko:
My bridge is defined in the style file before all highways:
(bridge=yes | bridge=true | bridge=viaduct) [0x2b resolution 23 continue
with_actions]
Better use ( bridge=* bridge!=no )
Henning
___
mkgmap-dev
Maybe bridge!=abandoned would also be useful.
Am 06.05.2013 11:40, schrieb Minko:
PS
I also added bridge!=proposed because I dont want to render bridges that
exists only on paper on the map ;-)
Better use ( bridge=* bridge!=no )
Henning
___
Hi Felix,
6365 takes only the real map tiles, while 6365* will take also the
_ovm.img-tiles as input. Maybe this causes problems, because mkgmap
doesn't know about the *_owm.img.
Henning
Am 07.05.2013 03:53, schrieb Felix Hartmann:
6365.img is somehow not the same as 6365*.img - even
Hi there,
would it be possible to create also a mkgmap-latest.zip and
mkgmap-stable.zip?
Actual you have to know the latest/stable version number of splitter and
mkgmap to download latest version. So it's pretty hard to create an easy
setup for a map-creator-tool or script.
Henning
Hi,
does this also needs a resolution=12 in splitter or are these different
things?
Henning
Am 07.05.2013 19:44, schrieb Felix Hartmann:
levels = 0:24, 1:22, 2:20, 3:18
overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12
___
mkgmap-dev mailing list
Maybe place=country would also be a nice thing for 12 and 14.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I'm trying it actual as an extended-poi. My thought was, that it makes
it easier on multi-country-maps for people without knowing much about
geography.
Henning
Am 07.05.2013 23:34, schrieb Felix Hartmann:
as a POI?
I think rather not. The boundary should suffice. At least for 12.
Then
Hi WanMil,
there is also the possibility, that both ways have the same direction
and one way uses oneway=-1. Then you will get both or no way, or am I wrong?
Henning
Am 14.05.2013 19:29, schrieb WanMil:
Hi Gerd,
the angle() function calculates the angle between start/end point of the
way
But this should be handled in options. Like:
min-size-polygon=0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1
Or is it necessary to handle it different for different polygon types?
Henning
Am 14.05.2013 23:25, schrieb Felix Hartmann:
b) A more optimal solution would be the following:
I've also problems with 0x9000 in qLandkarte. At least there is no name
displayed (I'm using a transparent icon).
Has someone discoverd which ranges of point-IDs work?
Henning
Am 16.05.2013 23:29, schrieb Felix Hartmann:
thanks.
However note, it's not only about 0x0100
I used 0x1000 and
Hi,
capital=yes is also used for regional capitals, eg. capital of a county
or lower administrative areas. Note: there are only 193 countries
accepted by UN and additional 13 ones not accepted. So I would recommend
to use is_capital=country in combination with place=city.
My experience tells
, May 20, 2013 at 11:07:53AM +0200, Henning Scholland wrote:
Hi,
capital=yes is also used for regional capitals, eg. capital of a county
or lower administrative areas. Note: there are only 193 countries
accepted by UN and additional 13 ones not accepted. So I would recommend
to use is_capital
Would be something like this in relations-file:
type=boundary admin_level=2 {
apply role=admin_centre {
set rrk:capital:country=yes
}
}
Henning
Am 20.05.2013 12:09, schrieb Henning Scholland:
Typical, the place-node of a capital should be a admin_center-member
Hi,
does someone has an explanation, why the second line isn't rendered in
the map? Only results of line 1 and 3 are visiblewith overview2
r2616(haven't tried other versions).
Henning
highway=trunk area!=yes access=no { set name='${name} (${ref})' |
'${ref}' | '${name}'} [0x10003 level 6
Am 20.05.2013 16:03, schrieb Felix Hartmann:
so far place=capital | place=capitol worked very well that's why I
put/proposed it in the default style. Have you checked that there are
actual capital cities, not capitol or capital?
For the mail here I just named one...
Which data are you using?
20.05.2013 16:06, schrieb Henning Scholland:
Hi,
does someone has an explanation, why the second line isn't rendered in
the map? Only results of line 1 and 3 are visiblewith overview2
r2616(haven't tried other versions).
Henning
highway=trunk area!=yes access=no { set name='${name} (${ref
I'm using the following for Germany:
# Germany = DEU
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level4=Hamburg {set
mkgmap:city='${mkgmap:admin_level4}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level4=Berlin {set
mkgmap:city='${mkgmap:admin_level4}' }
mkgmap:country=DEU
Hi,
if you fear, there will be regular new errors, then your local community
should thnk about a bot, fixing some misspellings in the data. Eg. in
Germany we have a bot fixing [sS]tr. or [sS]trasse to [sS]traße.
mkgmap shouldn't do there any black-box-things. This will make debugging
quite
Hi there,
while cycling in New Zealand I found out, thats a little bit toeasy just
taking a style (routing and map-look) and use it in parts of the world,
which are very different to Central Europe. Eg. it's not that
interesting if the road is a trunk or a unclassified, but it's very
Jepand it is working as expected. There is only a problem with
international cycle-routes in level 7 (res 14). They are not rendered
completely, but I'm investigating it. So don't know jet if it's a
problem in mkgmap or in style or in osm-relation (maybe to many
subrelations)
Henning
Am
Hi Thorsten,
if you say, that changing the version which every update prevents the
problem, then maybe --product-version should be set by default to
mmdd (date of generation) and not to 1.
Henning
Am 30.05.2013 12:59, schrieb Thorsten Kukuk:
On Thu, May 30, Bernd Weigelt wrote:
Am
Hi
If there is a name-field and a ref-field in Garmin-format, then I would
suggest to fill them with mkgmap:ref and mkgmap:name, if these tags are
not set or empty, use name and ref. Everything else should be handled in
style-file.
Also { name 'abc' } should be equal to { set name='abc'}.
Hi,
I discoverd, that the overviewmap doesn't use the given codepage (see
http://www.aighes.de/data/map.png and
http://www.aighes.de/data/overviewmap.png ). Isthis a limitation of
overview maps or is it just a bug?
Henning
___
mkgmap-dev mailing
Hi Steve,
I don't know which is the correct usage. But actual syntax in style
does only allow to use each level once. For me actual stylesyntax is
quiet logicaland should be kept. Otherwise you have
overview_level=number and level=numberand overview_level will also
influence normal map.
Hi Gerd and Steve,
works as expected! Great job!
Henning
Am 31.05.2013 15:19, schrieb GerdP:
Here is version 2 of the patch.
ov_codepage_v2.patch
http://gis.19327.n5.nabble.com/file/n5763527/ov_codepage_v2.patch
Compiled binary is here:
http://files.mkgmap.org.uk/download/126/mkgmap.jar
Do you have an example? I just take a quick look to Czech on osm.org,
but haven't found such parts in names.
I would suggest that you have to use the original string, because they
are just compared.
Henning
Am 06.06.2013 19:40, schrieb Felix Hartmann:
In Slovakia as well as Czech Republich
Hi Gerd,
what's about explaining in the wiki only the basic functions (without
default things) and in the beginning a short explanation with a link to
https://github.com/openstreetmap/mkgmap/blob/master/resources/help/en/options
Maybe it would also be better to mark options used by
Hi Gerd,
maybe it would be better to have for each Garmin-routing-group a
mkgmap:*-tag. E.g. mkgmap:car=*
These tags have to be set in style-file. So you have full control about
it and no black box.
Henning
Am 10.06.2013 20:21, schrieb GerdP:
Hi Chris,
don't know. A person that wants to
Hi Carlos,
maybe it would be a good hackto change the word order. E.g. Avenida
... = ..., Avenida
Henning
Am 02.07.2013 17:51, schrieb Carlos Dávila:
The maps are generated with --index parameter, the problem comes from
names starting with the kind of way, such as Calle, Avenida, Avda. etc.
Try
highway=* name ~ '.*[aA]venida' { set
foobar:name='${name|subst:Avenida |subst:avenida }, Avenida'}
...
foobar:name=* {set name='${foobar:name}'}
Henning
Am 02.07.2013 20:00, schrieb Carlos Dávila:
El 02/07/13 19:28, Henning Scholland escribió:
Hi Carlos,
maybe it would be a good
Am 06.07.2013 12:43, schrieb Johannes Formann:
After a short investigation a possible reason are large differences in the
road_type and road_speed.
Anyone observed a similar behaviour?
I think Felix reported this problem some time ago, but this shouldn't
have anything to do with the new
Take a look at: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dlock_gate
The part of the river between the lock-gates should have a tag
lock_name. If you move this to name-tag your problem should be fixed.
Like:
lock_name=* { set name='${lock_name}' }
Henning
Am 07.07.2013 12:34, schrieb
I would prefer a style-function like we have already for length of ways.
Eg. called polygon-size and returns the size in m². I think this is not
much more work, but it is a lot more flexible.
Henning
Am 10.07.2013 17:21, schrieb Felix Hartmann:
Well I recently noticed, that some super detail
Am 10.07.2013 20:13, schrieb Felix Hartmann:
what's the difference?
Hi, the unit isn't the real difference. If it's easyer to calculate
Garmin-units² it would also be ok. The difference between our the
proposals is: In my proposal you get the polygon-size as a value and can
handle it in
Hi WanMil,
take care, this proposal might be to big ;)
Maybe it would be better first solve the part with name-handling and
then continue with housenumber-matching.
For example: migrate name and ref handling in style-file and use only
mkgmap:name and mkgmap:ref for name and ref-fields.
Then
Hi WanMil,
great work!
Am 11.07.2013 23:04, schrieb WanMil:
The patch adds a new style function called garmin_area().
garmin_area() returns the size of an area in garmin-units ^2. It works
for polygons only. Unclosed ways return 0.
Please test it and let me know:
* Do you have a better
Am 20.07.2013 13:23, schrieb Greg Troxel:
WanMil wmgc...@web.de writes:
area_size() gives the area size on resolution 24. Your effects must have
another reason.
Maybe the function should be garmin24_area() instead, then. I
understand that it's good to have area in garmin units because
Hi Steve,
are there more sort-orders are missing? So maybe we should ask at
talk-mailinglist or at least create a wiki-page for that. I would write
such a mail, but don't know which parts are missing.
Henning
___
mkgmap-dev mailing list
Hi Andrze,
I think you have the knowledge to change the provided list. Eg. doing
this directly in the repository or sending a working file to this list ;)
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 26.07.2013 22:41, schrieb Andrzej Popowski:
Hi Henning,
I think you have the knowledge to change the provided list.
Unfortunately not. I can understand some parts of mkgmap code, but I
don't know it enough to modify. And I have never programmed in java.
Its just a simple txt-file ;)
Am 05.08.2013 13:00, schrieb Carlos Dávila:
highway=* name ~ '[Aa]venida [Dd]e [Ee]l .*' { add
streettype:movedend='${name|subst:Avenida De El |subst:Avenida De el
|subst:Avenida de El |subst:Avenida de el |subst:avenida De El
|subst:avenida De el |subst:avenida de El |subst:avenida de el
Am 05.08.2013 15:17, schrieb Enrico Liboni:
Carlos, Bueno! Thanks for your reply. Actually I believe trying to
find all the combinations in the various languages would really be
hard and I'm concerned about having hard-codes in for languages.
I don't think that this is a good solution.
1:
Am 05.08.2013 21:50, schrieb Enrico Liboni:
I believe that indexing just the last word make more sense to avoid a
lot of useless entries, since words in the middle are usually first
names or prepositions
At least in Germany this wont work well. ;)
Henning
Am 06.08.2013 16:21, schrieb Steve Ratcliffe:
I think it is much safer to give the flag than letting mkgmap guess
which can be wrong for all kinds of reasons.
Hi Steve,
I don't think this is a good solution. If you think mkgmap guessing is
not good enough, then this should be removed at all.
Am 10.08.2013 13:21, schrieb WanMil:
I think results for lat=x° should equal lat=-x°?
This is what I would expect too. See attached ods-worksheet.
$ro = 6371.0 //[km]
$a = (90.0 - $lat1) * M_PI / 180.0;
$b = (90.0 - $lat2) * M_PI / 180.0;
$gamma = (abs($lon2 - $lon1)) * M_PI / 180.0;
$c =
Hi, me again ;)
Of course in the worksheet l is also in m, not in km. There are small
differences between +/- lat because of calculating always the rectangle
above the latitude. So the values below lat=0 are a little bit larger.
Rounding may also have a influence.
Henning
Am 12.08.2013 10:31, schrieb Minko:
Hi,
I noticed there are many well paved roads tagged with mtb:scale=0 which are
automatically converted into unpaved by mkgmap.
Combinations like mtb:scale=0 surface=asphalt or mtb:scale=0
tracktype=grade1 should imho not get a tag mkgmap:unpaved=1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
thanks for the code (and of course for the idea to do something like
this). I will give it a try.
While adding it to my style I found maybe a bug with include style files.
I have a folder style_rrk, including a folder inc and points-file etc.
In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi WanMil,
I think the list should contain all tags which are used in
style-files, or are these keys are checked in a seperate way and the
list contains only internal tags?
Henning
Am 27.08.2013 21:31, schrieb WanMil:
For anyone who is interested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi WanMil,
so you are merging objects with the same Garmin-ID, unless they
containing one key of the mentioned list. In this case the list seems
to be quite ok. Wasn't there something like mkgmap:street or
streetname or am I wrong?
As you pointed out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'n not sure, but you are only covering the cases:
only digits
digits and mph
digits and kmh
asking taginfo, there are also km/h in the data (almost more often
then kmh). But my java-knowledge is not that good. So if I'm wrong
forgive me.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Toby,
the patch shouldn't change that much. If you actually use
- --ignore-maxspeed, then you havn't to change anything. If you actually
don't use --ignore-maxspeed, then you'll need to add a rule like
maxspeed=* { set mkgmap:maxspeed =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am 01.09.2013 23:29, schrieb Manfred Brenneisen:
You do a great job, and I really appreciate your work Thinking
about maxspeed:practical, which can be used to initialize maxspeed
in some cases, I thought about rural areas, which do not have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi WanMil,
I got the following list as an output:
SEVERE (RoadMerger): 1124.o5m: Through route 2174274/361817 [WAY:
79386593 null(46.65438652038574/7.7636003494262695)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
Am 04.09.2013 20:16, schrieb WanMil:
junction is used to detect roundabouts. We could map that to
mkgmap:junction but I am not sure if that really helps?
Maybe it would help in the point, that mkgmap internally only handels
tags with mkgmap:*.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I got the following error messages:
SEVERE (MapArea): Point with type 0x1e04 at
http://www.openstreetmap.org/?mlat=36.32080mlon=25.79590zoom=17 is
outside of the map area centred on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Typical you'll need something like
value(key1) = value(key2) {..} [..]
Then you can handle such cases. With curent style-functionality you
can just decide if you would prefer some Shell (Shell) or some
amenity=fuel without brand (in your case).
Hi,
I'm simplifying these things just in the beginning for all needed
cases. Eg.
bicycle=designated | bicycle=official {set bicycle=yes}
bicycle=private | ( access=private bicycle!=yes) { set access=no }
and so on. If you'll need the original values, you can use a
namespace. But I only care
Hi Gerd,
thanks for your answer.
Am 05.10.2013 16:10, schrieb Gerd Petermann:
Hi Henning,
I still have this on my todo list. The messages seem
to occur when creating the overview map. Maybe
it is an error in mkgmap.
Will I be able to reproduce the problem with the files from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Gerd,
Am 06.10.2013 13:58, schrieb GerdP:
4) For each generated polygon the POIGenerator creates a POI, the
position is calculated using method Way.getCofG(). This method
calculates the average latitude and longitude values of all points
of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 06.10.2013 20:06, schrieb WanMil:
What is your opinion about the two new actions? Do they help? Are
they sufficient? Are any other actions required?
Hi,
what about the following behavior:
all access-values are by default unset. You can set a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 07.10.2013 15:15, schrieb Marko Mäkelä:
should take care of the matching part, but I have no idea how it
could be replaced nicely. One possibility for future syntax could
be similar to how the Perl pattern-match operator works:
This should be
Am 08.10.2013 13:07, schrieb Marko Mäkelä:
Yes, and that is one reason why I posted about this to the Users:
Finland forum at http://forum.openstreetmap.org/viewforum.php?id=15.
I do not think that this is as bad a sin as mapping for a renderer,
but it does feel a bit wrong. On the
Am 12.10.2013 00:00, schrieb Steve Ratcliffe:
1st: shieldL276
2nd: Laacher Straße
The third and fourth positions would be for alternate names.
So we would need something like:
mkgmap:ref- 1st
mkgmap:name - 2nd
mkgmap:name_1 - 3rd
mkgmap:name_2 - 4th
Everything else should be done
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I think it's better to have only something like:
mkgmap:name:1
mkgmap:name:2
mkgmap:name:3
mkgmap:name:4
If [..] is processed the string of mkgmap:name:1..4 is written to the
file. If one tag is empty the next one in order is used. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.10.2013 10:33, schrieb Minko:
man_made=* area!=no
I think this is wrong in polygon-file. It should be:
man_made=* area=* area!=no
or:
man_made=* area=yes
In your version above, a man_made-object containing no area-tag is
handled as
Hi Claude
Unfortunately this isn't possible. There is no link between the river
and the riverbank. I think it's better to have such an information also
at the polygon, because the hole area is affected by this access-rule.
If you're unsure about this, you can ask also @tagging, if there is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Minko,
just a hint: Move these general rules to seperate files and include
them in each style-file of point, lines, etc.
Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Felix,
I think you should better use I instead of you, because I think
you're the only one with such complex style-sheets.
You could have a single line in the beginning like:
foot=private { set mkgmap:foot=no }
Everytime you had changed this
201 - 300 of 473 matches
Mail list logo
