[mkgmap-dev] conditional includes in style

[Gerd Petermann]

Hi Felix,

I've started a new thread for this as your post was a bit off topic here:
http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p5801182.html

I had the same idea when I tried to find a solution for the 
--make-opposite-cycleways option 
in the style, but then I thought that --make-opposite-cycleways should not be 
an option at all, 
these cycleways should be created in the default style if they don't cause any 
trouble.

Your proposition sounds like #ifdef / #endif in a c /c++ prepro combined with 
defines passed to the compiler.
I agree that this gives more flexibility, but it is also likely to reduce 
readability. 
The keyword includeoptional sounds more "include if you can find it".

Are there other ideas out there?

Gerd


  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Thorsten Kukuk]

On Thu, Mar 27, Gerd Petermann wrote:

> Your proposition sounds like #ifdef / #endif in a c /c++ prepro combined with 
> defines passed to the compiler.

This is what I'm doing with my style already. I use #ifdef/#endif
and before executing mkgmap I create a local copy of the style with
help of cpp.
I like that more, because I can check the resulting style and find
errors much easier then if I would need to guess what mkgmap is doing.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
I quote a mail, which I wrote some month ago to the list:

> 
> while cycling in New Zealand I found out, thats a little bit to
> easy 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 interesting to show if a road is sealed or unsealed.
> 
> If there are only small things, which are country-specific it's
> pretty easy to use just & mkgmap:country=???. But this will makes
> the style quite confusing to understand. So I thought it would be
> nice to have something like:
> 
> if ( == ) {  }
> 
> I think such a if-clause would also in general makes style-files a
> little bit more readabel and shouldn't be that complex to implement
> (or am I wrong?).
> 
> What do you think about such a if-clause? Maybe there is a better
> way for it.

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJTM9JDAAoJEPFgsWC7jOeTtzgIAIemvaXqXmSiR4G5p3DqaeCB
Z/xjbDHOp81KebkDmh36f3s+zpewPPhNusOb1H4qTT27xevXGvBeDMkbYLCpnkoO
Kdt+Ej9V5Bosmc6Yey0vs2uClAIC+2OUTXoulh2ZWy/3W4aYAJdtbIQH5IGPgUhY
Lh4N77bvIxfQck7fEDbCtxbjuLd56Z0zASO65kAGwo9OPjyWBHYbkZBMS/IBpdyp
pTTD89Gqf4MXgi6v1bHw/n/ePVD8l/4oV/p86mAtyUVaQk332YQr9Qoryq4PuDlY
XGPvPiuGk8waqsl2ZtZyEh7m7y2Zb8njBuHC2gKguqEzNjnsgjbIy4Heg26yI6E=
=O67V
-END PGP SIGNATURE-

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch v5] correct make-cycleways

[Gerd Petermann]

Hi Andrzej,

> patch v7 solves problem with second cycleway, support for 
> make-opposite-cycleways seems to be correct too.

puh :-)
Quite a lot of version for such a small patch ;-)

> 
>  > The artificial cycleways have the tag mkgmap:synthesised=yes
> 
> I can't guess how to use it. Could you provide an example?
no :-(

I thought that it could be done with a single ike this
highway=* & mkgmap:synthesised=yes & bicycle=yes [0x04 road_class=2 
road_speed=3 resolution 24]

but we probably also want different road classes for the cycleways 
depending on the highway=* tag value.

Maybe we can code a solution in the  section?
Something like
highway=* & mkgmap:synthesised=yes & mkgmap:bicycle=yes { set 
mkgmap:resolution-min = 24 }

That would work similar to the mkgmap:road-class-min=* tag.

The problem with this is that the original idea was that an  "Element type 
definition" 
(the stuff in the square brakets) is a constant, and the code required to allow
tags like mkgmap:road-class-min=* is very error-prone.

Gerd
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Gerd Petermann]

Hi Henning,

where would you want to set the  for  ?

Gerd

> Date: Thu, 27 Mar 2014 08:24:51 +0100
> From: o...@aighes.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] conditional includes in style
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Gerd,
> I quote a mail, which I wrote some month ago to the list:
> 
> > 
> > while cycling in New Zealand I found out, thats a little bit to
> > easy 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 interesting to show if a road is sealed or unsealed.
> > 
> > If there are only small things, which are country-specific it's
> > pretty easy to use just & mkgmap:country=???. But this will makes
> > the style quite confusing to understand. So I thought it would be
> > nice to have something like:
> > 
> > if ( == ) {  }
> > 
> > I think such a if-clause would also in general makes style-files a
> > little bit more readabel and shouldn't be that complex to implement
> > (or am I wrong?).
> > 
> > What do you think about such a if-clause? Maybe there is a better
> > way for it.
> 
> Henning
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.20 (MingW32)
> 
> iQEcBAEBAgAGBQJTM9JDAAoJEPFgsWC7jOeTtzgIAIemvaXqXmSiR4G5p3DqaeCB
> Z/xjbDHOp81KebkDmh36f3s+zpewPPhNusOb1H4qTT27xevXGvBeDMkbYLCpnkoO
> Kdt+Ej9V5Bosmc6Yey0vs2uClAIC+2OUTXoulh2ZWy/3W4aYAJdtbIQH5IGPgUhY
> Lh4N77bvIxfQck7fEDbCtxbjuLd56Z0zASO65kAGwo9OPjyWBHYbkZBMS/IBpdyp
> pTTD89Gqf4MXgi6v1bHw/n/ePVD8l/4oV/p86mAtyUVaQk332YQr9Qoryq4PuDlY
> XGPvPiuGk8waqsl2ZtZyEh7m7y2Zb8njBuHC2gKguqEzNjnsgjbIy4Heg26yI6E=
> =O67V
> -END PGP SIGNATURE-
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Gerd Petermann]

Hi Thorsten,
> 
> This is what I'm doing with my style already. I use #ifdef/#endif
> and before executing mkgmap I create a local copy of the style with
> help of cpp.
> I like that more, because I can check the resulting style and find
> errors much easier then if I would need to guess what mkgmap is doing.

I agree that this is a good solution as long as you don't want to publish
the input to cpp. If I remember correctly, the options to run different 
c++ compilers on different platforms are very different .

Gerd

  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] invalid rule expression

[Minko]

This rule does not work:
highway ~ 
'(secondary|tertiary|unclassified|residential|minor|living_street|service)' 
& oneway=* 
& (cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | 
oneway:bicycle=no | bicycle:oneway=no )
{set bicycle=no; set mkgmap:cycleway=yes}

Only if I put oneway=* first, it works, why?

oneway=* 
& highway ~ 
'(secondary|tertiary|unclassified|residential|minor|living_street|service)' 
& ( cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | 
oneway:bicycle=no | bicycle:oneway=no )
{set bicycle=no; set mkgmap:cycleway=yes}


The error message is:

Error in style: Error: (lines:119): Invalid rule expression: 
$cycleway='opposite')|(($cycleway='opposite_lane')|(($cycleway='opposite_track')|(($oneway:bicycle='no')|($bicycle:oneway='no')&$oneway=*)&($highway~'(secondary|tertiary|unclassified|residential|minor|living_street|service)'))
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r3132: refactoring handling of mkgmap:skipSizeFilter, no functional change

[svn commit]

Version mkgmap-r3132 was committed by gerd on Thu, 27 Mar 2014

refactoring handling of mkgmap:skipSizeFilter, no functional change
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [patch v8] correct make-cycleways and new mkgmap: tag

[Gerd Petermann]

Hi all,

attached is version 8 of the patch.

Compared to v7 it adds the handling of a new internal tag 
mkgmap:highest-resolution-only

If set to true, the minimum resolution of the object is changed to equal 
the maximum resolution. This also works when the style uses
level instead of resolution.
The default style is changed to set mkgmap:highest-resolution-only=true
for the added cycleways.

Gerd
  

cycleway-v8.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap logging problem/question

[Gerd Petermann]

Hi Thorsten,

sorry, did not see that typo before:
You have to write 
uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=SEVERE
not
uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation=SEVERE

Gerd

> Date: Wed, 26 Mar 2014 21:32:11 +0100
> From: ku...@suse.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap logging problem/question
> 
> 
> Hi Gerd,
> 
> On Wed, Mar 26, GerdP wrote:
> 
> > Hi Thorsten,
> > 
> > please check if you also have the line
> > uk.me.parabola.mkgmap.reader.osm.level=WARNING 
> > or maybe only
> > uk.me.parabola.mkgmap.reader.level=WARNING 
> > 
> > if yes, make sure that
> > uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation=SEVERE
> > comes after that.
> 
> Yes, I had that line. But it was already before 
> MultiPolygonRelation=SEVERE. Changing them didn't made a
> difference, too. So I removed it now and the output is what
> I need.
> 
> Thanks,
> Thorsten
> 
> > Gerd
> > 
> > 
> > Thorsten Kukuk wrote
> > > Hi,
> > > 
> > > I currently try to get ride of this thousands of warnings about
> > > "WARNING (MultiPolygonRelation): 7121.osm.pbf: Cannot join the
> > > following ways to closed polygons..."
> > > 
> > > So I have the following line in my logging.properties file:
> > > uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation=SEVERE
> > > 
> > > For all other cases this works fine, somehow only for the
> > > MultiPolygonRelation.class it seems to be ignored?
> > > Even if I remove that line, it's still printed. And yes, I'm sure
> > > I don't have it a second time in my file.
> > > 
> > > Any idea what I can make wrong?
> > > 
> > > Thanks,
> > > Thorsten
> > > 
> > > -- 
> > > Thorsten Kukuk, Senior Architect SLES & Common Code Base
> > > SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> > > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
> > > ___
> > > mkgmap-dev mailing list
> > 
> > > mkgmap-dev@.org
> > 
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > 
> > 
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://gis.19327.n5.nabble.com/mkgmap-logging-problem-question-tp5801190p5801203.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> -- 
> Thorsten Kukuk, Senior Architect SLES & Common Code Base
> SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Andrzej Popowski]

Hi Gerd,

here my idea:

1. Allow for nested conditions in style. For example current lines:

mkgmap:country=NLD & mkgmap:region!=* ...
mkgmap:country=NLD & mkgmap:city!=* ...

could be rewritten as:

mkgmap:country=NLD {
  do {
mkgmap:region!=* ...
mkgmap:city!=* ...
  }
}


2. Allow for user defined tags in mkgmap options, for example:

mkgmap.jar --style-option=topo;cycleways ...

And use them in style like tags from data:

style-option=topo { do {
 ...
 ...
}}
style-option!=cycleways { do {
 ...
 ...
}}
highway=residential & style-option=cycleways ...


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] invalid rule expression

[Steve Ratcliffe]

On 27/03/14 08:50, Minko wrote:

Only if I put oneway=* first, it works, why?


Its a good workaround for the bug, since it should go first. But mkgmap
is supposed to be able to re-arrange the terms so that it goes first 
itself and that is failing in this case.


I will add your example as a test and fix it.

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [patch v8] correct make-cycleways and new mkgmap: tag

[Andrzej Popowski]

Hi Gerd,

mkgmap:highest-resolution-only works for me.

But I have noticed another problem. Please see this road in the sample I 
have attached for v6 testing:

http://www.openstreetmap.org/way/258440157

mkgmap doesn't create opposite cycleway for this road. The same goes for 
trunk, patch v6 and v7. I think I have seen cycleway at this place, but 
maybe it was when I have tested definitions for cycleway in style.


--
Best regards,
Andrzej

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap logging problem/question

[Thorsten Kukuk]

On Thu, Mar 27, Gerd Petermann wrote:

> Hi Thorsten,
> 
> sorry, did not see that typo before:
> You have to write 
> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=SEVERE
> not
> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation=SEVERE

Thanks, this mistake explains it of course, now it's working
as it should.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Henning Scholland]

Hi Gerd,
maybe it gets a little bit clearer if I gave an example.

if ( mkgmap:country=DEU ) {
include 'deu_highway_rules';
}

or

if (mkgmap:country=DEU) {
highway=primary { set mkgmap:access=no }
highway=... {...}
...
}

Henning

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Marko Mäkelä]

First, the conditional rules or includes sounds like a good idea. I 
guess we should only allow the new syntax for key=value or maybe key=*.


Should we introduce a new type of keys (global keys) that are not 
associated with any OSM object?


Or, should the global keys be the default on every object? For example, 
after


java -jar mkgmap.jar --add-default-way-tag=name=unknown

every OSM way that did not already carry a name=* tag would be tagged 
with name=unknown.


On Thu, Mar 27, 2014 at 12:15:14PM +0100, Andrzej Popowski wrote:

2. Allow for user defined tags in mkgmap options, for example:

mkgmap.jar --style-option=topo;cycleways ...


; would be a bad choice for a delimiter, because it is a shell 
meta-character in the conventional Unix shells (separating commands when 
you do not want to use line breaks).


Also, I think that the option should be split already on the command 
line, like this:


java -jar mkgmap.jar --style-option=topo --style-option=cycleways ...

In many Unix shells, you can use short-hand notation which would be 
expanded to the above by the shell:


java -jar mkgmap.jar --style-option={topo,cycleways}

Best regards,

Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Andrzej Popowski]

Hi Marko,

> Should we introduce a new type of keys (global keys) that are not
> associated with any OSM object?

This would be handy for conditional interpreting of style.


> java -jar mkgmap.jar --add-default-way-tag=name=unknown

Or maybe that way:
 mkgmap.jar --style-option=default_name=unknown

And then in style:
 highway=* & name!=* { add name = '${style-option:default_name}' }

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Felix Hartmann]

That is also quite nice, my main problem with this approach is - can we 
by now assume that the mkgmap:country tag is 99.9% available correctly 
when using precompiled bounds?


if not passing options from commandline is in this case more reliable - 
because if you know that you only have input from one country, then give 
options on commandline aobut include - and not read a tag from data. 
Also I would suppose this is quicker.


Of course if you build a Europe map, or another multi country map - then 
better use from the style. But that's exactly why actually both 
conditional includes would be useful.




As for C# - I would really prefer to have it handled by mkgmap as it's 
more universal and I would bet it will become quite popular/useful for 
many style(s)/style writers.

On 27.03.2014 16:32, Henning Scholland wrote:

Hi Gerd,
maybe it gets a little bit clearer if I gave an example.

if ( mkgmap:country=DEU ) {
include 'deu_highway_rules';
}

or

if (mkgmap:country=DEU) {
highway=primary { set mkgmap:access=no }
highway=... {...}
...
}

Henning

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [patch v8] correct make-cycleways and new mkgmap: tag

[GerdP]

Hi Andrzej,


found the error: the tags oneway:bicycle and bicycle:oneway very only
evaluated when
they appeared in the style. They have to added to the internal usedTags
list.
Attached is version 9 which corrects this error.

cycleway-v9.patch
  

Gerd


popej wrote
> Hi Gerd,
> 
> mkgmap:highest-resolution-only works for me.
> 
> But I have noticed another problem. Please see this road in the sample I 
> have attached for v6 testing:
> http://www.openstreetmap.org/way/258440157
> 
> mkgmap doesn't create opposite cycleway for this road. The same goes for 
> trunk, patch v6 and v7. I think I have seen cycleway at this place, but 
> maybe it was when I have tested definitions for cycleway in style.
> 
> -- 
> Best regards,
> Andrzej
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/patch-v8-correct-make-cycleways-and-new-mkgmap-tag-tp5801275p5801342.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about turn restriction warning

[Thorsten Kukuk]

Hi,

what does this message in the mkgmap log want to say me?

2014/03/27 12:22:15 WARNING (RestrictionRelation): 71200255.osm.pbf: Turn 
restriction http://www.openstreetmap.org/browse/relation/1631712 (at 
http://www.openstreetmap.org/?mlat=51.609756&mlon=7.509406&zoom=17) 
no_left_turn 'via' coord redefined from 
http://www.openstreetmap.org/?mlat=51.609508&mlon=7.518603&zoom=17 to 
http://www.openstreetmap.org/?mlat=51.609508&mlon=7.518603&zoom=17

I have quite a lot of them, but the interesting part is, that
the from URL seems to be always identical to the to URL.
At least I wasn't able to find an entry where it is different.
And is a WARNING here really correct? For me it looks more
like this should be a debug or info message?

Thanks,
  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Marko Mäkelä]

On Thu, Mar 27, 2014 at 07:59:24PM +0100, Felix Hartmann wrote:
That is also quite nice, my main problem with this approach is - can 
we by now assume that the mkgmap:country tag is 99.9% available 
correctly when using precompiled bounds?

[snip]

if ( mkgmap:country=DEU ) {
   include 'deu_highway_rules';
}


Would this mkgmap:country be assumed to be constant for all map objects?  
If mkgmap builds a rectangular map tile that includes a bit of Germany, 
Austria and Switzerland, would this include be executed unconditionally, 
and each rule in it would be prefixed with the condition 
"mkgmap:country=DEU &"?


If the include statement is dynamic, what if the first objects in the 
OSM extract happen to be outside Germany? Would you then skip the 
include for all of the map tile, skipping it for the German part of the 
tile? If the first objects are inside Germany (mkgmap:country=DEU 
holds), would the rules be applied to all subsequent map objects, no 
matter if mkgmap:country=DEU holds for them?


Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about turn restriction warning

[GerdP]

Hi Thorsten,

please ignore it. It will be corrected in the via-way branch.

Gerd


Thorsten Kukuk wrote
> Hi,
> 
> what does this message in the mkgmap log want to say me?
> 
> 2014/03/27 12:22:15 WARNING (RestrictionRelation): 71200255.osm.pbf: Turn 
> restriction http://www.openstreetmap.org/browse/relation/1631712 (at 
> http://www.openstreetmap.org/?mlat=51.609756&mlon=7.509406&zoom=17) 
> no_left_turn 'via' coord redefined from 
> http://www.openstreetmap.org/?mlat=51.609508&mlon=7.518603&zoom=17 to 
> http://www.openstreetmap.org/?mlat=51.609508&mlon=7.518603&zoom=17
> 
> I have quite a lot of them, but the interesting part is, that
> the from URL seems to be always identical to the to URL.
> At least I wasn't able to find an entry where it is different.
> And is a WARNING here really correct? For me it looks more
> like this should be a debug or info message?
> 
> Thanks,
>   Thorsten
> 
> -- 
> Thorsten Kukuk, Senior Architect SLES & Common Code Base
> SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-turn-restriction-warning-tp5801351p5801355.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

[Michał Rogala]

2014-03-27 19:59 GMT+01:00 Felix Hartmann :

> That is also quite nice, my main problem with this approach is - can we by
> now assume that the mkgmap:country tag is 99.9% available correctly when
> using precompiled bounds?
>
>
I wouldn't take that for granted - I use my own Europe extract of Poland
and border areas of neighbour contries, I generate precompiled boundaries
but often a lot of places outside Poland get mkgmap:country  assigned as
'POL' because I use --country-abbr=POL and  level 2 administrative
boundaries are so incomplete (as extract do not cover whole countries, only
their parts) that mkgmap can't process them.


best regards

Michal Rogala
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with address search and --code-page

[Michał Rogala]

Hi!

This bug is tricky as hell :).

Here are my observations:

1) No separate tile causes broken index. This only happens when all (or at
least unknown combination of) tiles are compiled together.
2) After many hours of testing I've selected 2 particular tiles. When I
remove them from my compilation, index starts working again.

3) Those 2 tiles - 6600435 and 6600436 cover border parts of Ukraine. I
suppose Ukrainian transliterated names cause problems. My guess would be
cities like: Volia-Baraniets'Ka or Ostrozhiets' (note apostrophe at the end)

4) I uploaded my splitted map here:

https://mega.co.nz/#!8l1jCLSR!x9FhsFVzLa6T7OfvYb-jYglP6voK04BcVwWHeeu7Hhw

here are generated boundaries:

https://mega.co.nz/#!R5k1iZqS!2UDuibgP1BAXNbh5FMMp3yt_5U5dyJBrh5hvObMVl0o


If you try to compile this map, please use particular config file, as I may
be crucial for replication of this bug:

verbose
max-jobs
country-name=Polska
name-tag-list=name:pl,name
generate-sea
location-autofill=is_in,nearest
tdbfile
index
add-pois-to-areas
link-pois-to-ways
remove-short-arcs
preserve-element-order
country-abbr=POL
route
net
gmapsupp
nsis
check-styles
process-exits
process-destination
housenumbers
overview-mapnumber=66007001
overview-levels=6:16,7:15

best regards

Michal Rogala


2014-03-26 10:54 GMT+01:00 Michał Rogala :

>
>
>
> 2014-03-25 23:40 GMT+01:00 Steve Ratcliffe :
>
>
>
>> You say that it works when loaded on to the device using MapSource? In
>> that case it cannot be the spaces themselves that is a problem, and I
>> made a fix for dealing with them that was included in that patch.
>>
>> So how badly does it not work? Can you search for anything? Is it only
>> addresses you can't find?
>>
>> Since a small map worked you may be able to find a group of tiles
>> that work and work out if there is a particular tile that makes it
>> go wrong.
>>
>>
> Maps work on MapSource and BaseCamp. Maps loaded using BaseCamp work on my
> device. To find an address Garmin asks you to enter country and then city
> (and later street). Device doesn't see any city to choose/search for.
>
> I'll try to find tiles that cause this problem.
>
> best regards
>
> Michal Rogala
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev