[mkgmap-dev] 2 pois for a single polygon/multipolygon

[maning sambale]

This way is tagged as a amenity=townhall and a multipolygon relation:
http://www.openstreetmap.org/browse/way/24159829
http://www.openstreetmap.org/browse/relation/452620

In my style:
polygons:
building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24]

and in the points:
amenity=townhall [0x3003 resolution 21]
building=* [0x6402 resolution 24]

I have the add-pois-areas switch enabled

This resulted to two POI icons (the little PH flag) in garmin
http://farm2.static.flickr.com/1290/5184379090_bbeeeaffc8_b.jpg
-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Greg Troxel]

maning sambale  writes:

> This way is tagged as a amenity=townhall and a multipolygon relation:
> http://www.openstreetmap.org/browse/way/24159829
> http://www.openstreetmap.org/browse/relation/452620
>
> In my style:
> polygons:
> building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24]
>
> and in the points:
> amenity=townhall [0x3003 resolution 21]
> building=* [0x6402 resolution 24]
>
> I have the add-pois-areas switch enabled
>
> This resulted to two POI icons (the little PH flag) in garmin
> http://farm2.static.flickr.com/1290/5184379090_bbeeeaffc8_b.jpg

So I think that the relation inherits tags from the outer way, and thus
both the multipolygon and the way get a poi point generated.  I don't
think this is a mkgmap bug.

What if you take the amenity/buiding/name tags off the outer way and put
them on the relation?  I am coming to the tenative conclusion that the
map data is wrong.  Or can you point to the rules for multipolygons and
buildings that say putting the data on an outer way is correct?




pgp5bSmHfnN32.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Chris66]

Am 17.11.2010 13:34, schrieb Greg Troxel:

> So I think that the relation inherits tags from the outer way, and thus
> both the multipolygon and the way get a poi point generated.  I don't
> think this is a mkgmap bug.

Another possible reason: The MP Code splits the MP to several "normal"
polygons (without holes), each getting a POI. But this is just a guess.

Chris

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

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[maning sambale]

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.

On Wed, Nov 17, 2010 at 8:34 PM, Greg Troxel  wrote:
>
> maning sambale  writes:
>
>> This way is tagged as a amenity=townhall and a multipolygon relation:
>> http://www.openstreetmap.org/browse/way/24159829
>> http://www.openstreetmap.org/browse/relation/452620
>>
>> In my style:
>> polygons:
>> building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24]
>>
>> and in the points:
>> amenity=townhall [0x3003 resolution 21]
>> building=* [0x6402 resolution 24]
>>
>> I have the add-pois-areas switch enabled
>>
>> This resulted to two POI icons (the little PH flag) in garmin
>> http://farm2.static.flickr.com/1290/5184379090_bbeeeaffc8_b.jpg
>
> So I think that the relation inherits tags from the outer way, and thus
> both the multipolygon and the way get a poi point generated.  I don't
> think this is a mkgmap bug.
>
> What if you take the amenity/buiding/name tags off the outer way and put
> them on the relation?  I am coming to the tenative conclusion that the
> map data is wrong.  Or can you point to the rules for multipolygons and
> buildings that say putting the data on an outer way is correct?
>
>
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[maning sambale]

Can anyone confirm this? (I don't read code sorry)

On Wed, Nov 17, 2010 at 8:44 PM, Chris66  wrote:
> Am 17.11.2010 13:34, schrieb Greg Troxel:
>
>> So I think that the relation inherits tags from the outer way, and thus
>> both the multipolygon and the way get a poi point generated.  I don't
>> think this is a mkgmap bug.
>
> Another possible reason: The MP Code splits the MP to several "normal"
> polygons (without holes), each getting a POI. But this is just a guess.
>
> Chris
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Marko Mäkelä]

On Wed, Nov 17, 2010 at 09:37:17PM +0800, maning sambale wrote:
>Can anyone confirm this? (I don't read code sorry)

If moving all tags from the role=outer way to the multipolygon relation 
fixes the problem, then Greg Troxel is right. If not, then Chris is 
right. I may have observed similar behaviour to what Chris mentioned, 
but that was months ago, and the code has been changed since then.

Marko

>
>On Wed, Nov 17, 2010 at 8:44 PM, Chris66  wrote:
>> Am 17.11.2010 13:34, schrieb Greg Troxel:
>>
>>> So I think that the relation inherits tags from the outer way, and thus
>>> both the multipolygon and the way get a poi point generated.  I don't
>>> think this is a mkgmap bug.
>>
>> Another possible reason: The MP Code splits the MP to several "normal"
>> polygons (without holes), each getting a POI. But this is just a guess.
>>
>> Chris
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
>
>-- 
>cheers,
>maning
>--
>"Freedom is still the most radical idea of all" -N.Branden
>wiki: http://esambale.wikispaces.com/
>blog: http://epsg4253.wordpress.com/
>--
>___
>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] 2 pois for a single polygon/multipolygon

[Torsten Leistikow]

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 2 - no tag

relation
type=multipolygon
amenity=townhall
way 1 = outer
way 2 = inner

In the beginning of multipolygon usage also the following scheme was used, but
is considered faulty now.
way 1 - amenity=townhall
way 2 - amenity=townhall

relation
type=multipolygon
way 1 = outer
way 2 = inner

Such an outdated tagging would result in two icons and should be considered as a
tagging fault.

If one of the first two solutions results in two icons, than the
add-pois-to-areas function of mkgmap does not work correctly in combination with
multipolygons.
(In my point of view the add-pois-to-areas function should be reworked anyway,
to give more control via the style file about which areas should generated which
POIs.)

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

[mkgmap-dev] !< not working -- problem with conditions in style-file.

[Felix Hartmann]

There is a problem in the style handling. "!<" is not working.
Assume I would like to reverse the statement
layer<0
into meaning layer < 0 does not exist. Currently I could write layer!=-1 
& layer!=-2 and so on. But that sums up to quite a lot of text.

Essentially I would like to have the following statement shorter...:
& ( tracktype!=1 | tracktype!=2 | tracktype!=3 | tracktype!=4 | 
tracktypeadded=yes )

but replacing it with
& (tracktype!<5 | tracktypeadded=yes )

does not yield the same outcome. Have I got a logical problem, or is it 
mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] !< not working -- problem with conditions in style-file.

[Marko Mäkelä]

On Wed, Nov 17, 2010 at 07:43:32PM +0100, Felix Hartmann wrote:
>There is a problem in the style handling. "!<" is not working.

How should it work? I haven't seen such an operator in any language. The 
SGML start-of-comment =, or is that not working either?

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

Re: [mkgmap-dev] !< not working -- problem with conditions in style-file.

[aighes]

Hello

instead of !< you could use => or >=. I don't know if there is a difference.
For example: 
& ( tracktype>=5 | tracktypeadded=yes )
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/not-working-problem-with-conditions-in-style-file-tp5748938p5749098.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] !< not working -- problem with conditions in style-file.

[Torsten Leistikow]

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!=* | tracktype<5)

The difference is, when there is no tracktype defined at all.

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

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Chris66]

>> Another possible reason: The MP Code splits the MP to several
>> "normal" polygons (without holes), each getting a POI. But this
>> is just a guess.

> Can anyone confirm this? (I don't read code sorry)

Hi, I created a test file with one park and one golf_course.
Number of POIs seems to match the number of holes:



So if my theory is correct, a possible solution:

MP code marks all generated "normal" polygons except
one with a flag. add-pois-to-areas ignores flagged
polygons.

Chris

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

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Chris66]

> Number of POIs seems to match the number of holes:
> 
> 

Result is the same if tagging the relation and not
the outer way.

Chris

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

Re: [mkgmap-dev] !< not working -- problem with conditions in style-file.

[Felix Hartmann]

On 17.11.2010 20:32, Torsten Leistikow wrote:
> 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!=* | tracktype<5)
>
> The difference is, when there is no tracktype defined at all.
For all ways that have no tracktype, I add a tracktype if I think a 
certain surface value reflects a tracktype.
Then later on however, depending or not whether the tracktype existed 
naturally or was added based on surface, do or do not do an action. And 
this action is also dependant on the value of the tracktype itself.

The full command working goes like this:
sac_scale=hiking & ((tracktype!=1 | tracktype!=2 | tracktype!=3 | 
tracktype!=4) | tracktypeadded=yes )  [0x07 ...]
And I tried to shorten it by changing it to
sac_scale=hiking & ( tracktype!<5 | tracktypeadded=yes)
but this does not give the same result - because for tracktype=5 the 
condition of tracktype smaller 5 not existing was not fullfilled. 
(double negation - seams not to be like by programmers either...).

Or in more detail so you can understand what I want.
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 exist, or 
tracktype has any value but 1-4 then it should also go through)
if tracktype=1 but tracktypeadded!=yes THEN do not build 0x07


((tracktype!=* | tracktype<5) | tracktypeadded=yes) does not work 
because the outcome would be
if tracktypeadded=yes THEN build 0x07
if tracktype=5 THEN do no build 0x07!!!
if tracktype=1 THEN do not build 0x07

!!! is the problem. Because in case that neither tracktype is under 
5 nor tracktypeadded=yes I still do want 0x07 to be built.
What actually works and at the same time makes the command shorter is:

sac_scale=hiking & ((tracktype!=* | tracktype>4) | tracktypeadded=yes)
still I would fine sac_scale=hiking & ( tracktype!<5 | 
tracktypeadded=yes) to be more elegant and shorter (though yes I do 
admit, double negations do cause confusion).


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

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[Greg Troxel]

Marko Mäkelä  writes:

> On Wed, Nov 17, 2010 at 09:37:17PM +0800, maning sambale wrote:
>>Can anyone confirm this? (I don't read code sorry)
>
> If moving all tags from the role=outer way to the multipolygon relation 
> fixes the problem, then Greg Troxel is right. If not, then Chris is 
> right. I may have observed similar behaviour to what Chris mentioned, 
> but that was months ago, and the code has been changed since then.

I think we first need to be very sure about the correct tagging rules
and then make mkgmap follow them.  It seems odd for me if tags belong on
the outer way member of a relation, but if so then relations shouldn't
use inherited tags for creating POIs.


pgpBqLwtjSkm4.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon

[maning sambale]

As far as I remember it, It should to be tagged in the outer way.  But
the wiki says otherwise,
http://wiki.openstreetmap.org/wiki/Multipolygon#Usage

On Thu, Nov 18, 2010 at 9:03 AM, Greg Troxel  wrote:
>
> Marko Mäkelä  writes:
>
>> On Wed, Nov 17, 2010 at 09:37:17PM +0800, maning sambale wrote:
>>>Can anyone confirm this? (I don't read code sorry)
>>
>> If moving all tags from the role=outer way to the multipolygon relation
>> fixes the problem, then Greg Troxel is right. If not, then Chris is
>> right. I may have observed similar behaviour to what Chris mentioned,
>> but that was months ago, and the code has been changed since then.
>
> I think we first need to be very sure about the correct tagging rules
> and then make mkgmap follow them.  It seems odd for me if tags belong on
> the outer way member of a relation, but if so then relations shouldn't
> use inherited tags for creating POIs.
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev