Re: [mkgmap-dev] closed ways and multi-polygon relations
Hi, first I'd like to say it works as intended, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=1694 Unfortunately WanMil is no longer active here, so I have no way to ask him why he deicded to use copies of the original ways instead of the joined way. Anyway, for ways with mkgmap:mp_created=true one should not use is_closed(), the important information is in mkgmap:stylefilter. I think the current implementation is not good because it creates lots of objects instead of a few, maybe only one. Each one is processed in the style and later the mergel-ine algo tries to put them together again. Gerd popej wrote > Hi Gerd, > > > are in fact copies of the original way members of the MP and those are > > typically not closed > > I see 3 possible solutions: > 1. Convert multipolygon ways to a proper, continuous outline. > 2. Return is_closed() as true, when mkgmap:mp_created is true. > 3. Add info to documentation, that lines with mkgmap:mp_created=true are > part of a closed outline, but not necessary result in is_closed()=true. > > I would suggest solution 3. > > I assume that is_closed() means, that object could be a polygon, while > mkgmap:mp_created=true or area=yes describe a more complex object, but > essentially a kind of polygon too. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd, > are in fact copies of the original way members of the MP and those are > typically not closed I see 3 possible solutions: 1. Convert multipolygon ways to a proper, continuous outline. 2. Return is_closed() as true, when mkgmap:mp_created is true. 3. Add info to documentation, that lines with mkgmap:mp_created=true are part of a closed outline, but not necessary result in is_closed()=true. I would suggest solution 3. I assume that is_closed() means, that object could be a polygon, while mkgmap:mp_created=true or area=yes describe a more complex object, but essentially a kind of polygon too. -- 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] closed ways and multi-polygon relations
Hi Ticker,
okay, I can reproduce the results. I was wrong, the ways with
mkgmap:mp_created=true and mkgmap:stylefilter=polyline
are in fact copies of the original way members of the MP and those are
typically not closed.
No idea why it is implemented this way. Looks wrong to me.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 22. November 2018 19:16
An: mkgmap development
Betreff: Re: [mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd
What I was expecting was that multiPolygonRelation generates 1 closed
way per distinct outer polyon and this has just the tags of the
relation. This is passed to 'lines' and 'polygons' matching.
My example is relation/1371699 which uses 9 ways (a mix of existing
roads and ways just created for the purpose) as outers to define a
single polygon.
What I'm seeing, with these in 'lines':
name='Littleton' & place=village & is_closed()=true {echotags
'lineLitVilTrue'}
name='Littleton' & place=village & is_closed()=false {echotags
'lineLitVilFalse'}
name='Littleton' & place=village [0x12 resolution 22]
1/ is no output from lineLitVilTrue
2/ 9 identical ways from lineLitVilFalse; I've removed some admin tags:
Way generated from 1371699 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polyline, name=Littleton, place=village]
lineLitVilFalse
Way generated from 1371699 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polyline, name=Littleton, place=village]
lineLitVilFalse
etc
3/ using GPSMapEdit, the generated line looks to be in 4 segments, some
of the outers from the relation have been joined, but it looks like it
has avoided joining where the base way tags conflict.
With this in 'polygons':
name='Littleton' & place=village {echotags 'polyLitVil'}
and, as in default style:
place=village [0x03 resolution 22]
I get:
JoinedWay generated from 94665254 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polygon, name=Littleton, place=village] polyLitVil
which is as expected, and it shows correctly on the map.
I'm pretty sure the relation and have just loaded the latest data from
geofabrik .
I get about 4500 messages running 1 map tile with this in 'lines':
mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
Ticker
On Thu, 2018-11-22 at 16:18 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand what you expect here. The ways with tag
> mkgmap:mp_created
> are the result of the joining process. Normally they are closed.
> Is the one way that is reported a part of a broken MP?
> Maybe you expect that the members of a MP rel do also have a special
> tag?
> That would be something that you have to do in the relations style
> file.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 22. November 2018 17:03
> An: mkgmap development
> Betreff: [mkgmap-dev] closed ways and multi-polygon relations
>
> Hi Gerd
>
> I'd hoped and expected that all polygons were fed into the 'lines'
> style processing in a similar manner, regardless of their origin as
> either a closed OSM way or generated by multiPolygonRelation. This
> would allow simple testing using just 'is_closed()=true' to effect
> lines around polygons if required.
>
> Instead I find that, for a few examples I've looked at in detail, for
> each outer way in a relation a way is passed into 'lines'. They all
> have identical tags (from the relation) and is_closed()=false. It is
> difficult to determine if these correspond directly to the ways in
> the
> relation.
>
> In the generated map, the line around the area might be in multiple
> segments, so some logic appears to have merged some of the ways but
> not
> others. In my example is seems as if merging has been prevented when
> the original ways have conflicting tags (maybe just the name=)
>
> Given that it isn't possible to differentiate the multiple outer ways
> when passed in from multiPolygon, why doesn't it just pass in the
> joined way that will be passed to the 'polygons' processing.
>
> Also, assuming that later processing is joining some of these parts,
> what stops it joining them all.
>
> I can give you details of my example if required, but just having:
>
> mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
>
> in 'lines' then looking for consecutive identical 'Way generated
> from...' output and checking that there is only 1 output polygon will
> yield a lot.
>
> Another difference between closed ways and multi-polygons is that
> with
> a closed way the object is passed through the rules of 'lines'
> concatenated with 'polygons' and all the facilties of stopping after
> a
> match/continue/with_actions work in a nice way, whereas with a multi
> -polygon, even if it matches in 'lines', it is passed through
> 'polygons' as w
Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Gerd,
great idea and it works good for my puposes. In principle I try to do the
following:
Use Option –add-pois-to-lines
• Add a tag route_mtb_info_point to the first member of a route
• Add all the relevant relation Information
• Add the „direction“ (role=backward/Forward) of the first member
• Add an element in the Points-file which is shown at the start or the end (or
in the middle if there is no direction) in relation of the direction of the way
I can search for POI like „MTB-Info…“ and get all the MTB-Routes around my
Position. The POI are at the start (or nearby) of the route (if the mebers are
ordered) or somewhere on the route – as expected. Sometimes there are two POI
for one route
I have the following in my style:
#add tag for direction to each member, could be both if way is twice or more
with diff Direction in the route.
route=mtb{apply
role ='backward'{set mtb_role_backward="yes";}
}
route=mtb {apply
role ='forward'{ set mtb_role_forward="yes";}
}
#save data of first member of the route, (could be more than one route but not
relevant in this example)
route=mtb{apply_first {
set
route_mtb_info_point="yes";
set
route_mtb_info_point_forward="$(mtb_role_forward)";
set
route_mtb_info_point_backward="$(mtb_role_backward)";
set
route_mtb_name="$(route_mtb_name)-${name}"|"${name}";
set
route_mtb_ref="$(route_mtb_ref)-${ref}"|"${ref}";
set
route_mtb_info_actual ="HM:k.A.,KM:k.A.";
set
route_mtb_info_actual="HM:${ascent},KM:${distance}" |
"HM:${fee},KM:${distance}" | "KM:${distance}" | "HM:${ascent}";
set
route_mtb_info="$(route_mtb_info)-$(route_mtb_info_actual)"|"$(route_mtb_info_actual)";
echotags"rel
apply_first"
}
I expected that for a way which is only member of one relation the values of
route_mtb_info_point_forward and route_mtb_info_point_backward
could never be „yes“ at the same time for both, because only the first member
of the relation is under investigation. But it seems that if a way is more than
once a member in a relation, the data of both positions are stored (the way is
the first (backward) and the last (Forward) member of the relation).
Way 337595135 [highway=track, motor_vehicle=forestry, mtb_role_backward=yes,
mtb_role_forward=yes, route_bicycle=yes, route_hiking=yes,
route_mtb_info=HM:754,KM:30, route_mtb_info_actual=HM:754,KM:30,
route_mtb_info_point=yes, route_mtb_info_point_backward=yes,
route_mtb_info_point_forward=yes, route_mtb_name=MTB-Strecke Breuberg 1,
route_mtb_ref=Bb1, route_name=Odenwaldklub HW 27, Seligenstadt - Waldbrunn -
Bad Rappenau-2-Burgen-Radweg-Rundwanderweg Breuberg Burg Breuberg 3:
Scheuerberg-Weg-Rundwanderweg Breuberg Burg Breuberg 2:
Schanzen-Weg-Rundwanderweg Breuberg Burg Breuberg 2:
Schanzen-Weg-Südhessen-Route 22, route_ref=HW 27-2BR-3-2-2-22,
route_symbol=rotes X auf weißem Grund, tracktype=grade2] rel apply_first
The Points – file includes the following:
route_mtb_info_point="yes" & route_mtb_info_point_forward="yes" &
mkgmap:line2poitype=start {set mkgmap:label:1 = "MTB-Info: ${route_mtb_ref}
${route_mtb_name} ${route_mtb_info}"}[0x1010a resolution 20-24 ]
route_mtb_info_point="yes" & route_mtb_info_point_backward="yes" &
mkgmap:line2poitype=end {set mkgmap:label:1 = "MTB-Info: ${route_mtb_ref}
${route_mtb_name} ${route_mtb_info}"}[0x1010a resolution 20-24 ]
route_mtb_info_point="yes" & mkgmap:line2poitype=mid &
route_mtb_info_point_backward!=* & route_mtb_info_point_forward!=* {set
mkgmap:label:1 = "MTB-Info: ${route_mtb_ref} ${route_mtb_name}
${route_mtb_info}"}[0x1010a resolution 20-24 ]
This results in 2 POIs for this route.
Andreas
Gesendet von Mail für Windows 10
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd
What I was expecting was that multiPolygonRelation generates 1 closed
way per distinct outer polyon and this has just the tags of the
relation. This is passed to 'lines' and 'polygons' matching.
My example is relation/1371699 which uses 9 ways (a mix of existing
roads and ways just created for the purpose) as outers to define a
single polygon.
What I'm seeing, with these in 'lines':
name='Littleton' & place=village & is_closed()=true {echotags
'lineLitVilTrue'}
name='Littleton' & place=village & is_closed()=false {echotags
'lineLitVilFalse'}
name='Littleton' & place=village [0x12 resolution 22]
1/ is no output from lineLitVilTrue
2/ 9 identical ways from lineLitVilFalse; I've removed some admin tags:
Way generated from 1371699 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polyline, name=Littleton, place=village]
lineLitVilFalse
Way generated from 1371699 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polyline, name=Littleton, place=village]
lineLitVilFalse
etc
3/ using GPSMapEdit, the generated line looks to be in 4 segments, some
of the outers from the relation have been joined, but it looks like it
has avoided joining where the base way tags conflict.
With this in 'polygons':
name='Littleton' & place=village {echotags 'polyLitVil'}
and, as in default style:
place=village [0x03 resolution 22]
I get:
JoinedWay generated from 94665254 [landuse=residential,
mkgmap:cache_area_size=99714.294, mkgmap:mp_created=true,
mkgmap:stylefilter=polygon, name=Littleton, place=village] polyLitVil
which is as expected, and it shows correctly on the map.
I'm pretty sure the relation and have just loaded the latest data from
geofabrik .
I get about 4500 messages running 1 map tile with this in 'lines':
mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
Ticker
On Thu, 2018-11-22 at 16:18 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand what you expect here. The ways with tag
> mkgmap:mp_created
> are the result of the joining process. Normally they are closed.
> Is the one way that is reported a part of a broken MP?
> Maybe you expect that the members of a MP rel do also have a special
> tag?
> That would be something that you have to do in the relations style
> file.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 22. November 2018 17:03
> An: mkgmap development
> Betreff: [mkgmap-dev] closed ways and multi-polygon relations
>
> Hi Gerd
>
> I'd hoped and expected that all polygons were fed into the 'lines'
> style processing in a similar manner, regardless of their origin as
> either a closed OSM way or generated by multiPolygonRelation. This
> would allow simple testing using just 'is_closed()=true' to effect
> lines around polygons if required.
>
> Instead I find that, for a few examples I've looked at in detail, for
> each outer way in a relation a way is passed into 'lines'. They all
> have identical tags (from the relation) and is_closed()=false. It is
> difficult to determine if these correspond directly to the ways in
> the
> relation.
>
> In the generated map, the line around the area might be in multiple
> segments, so some logic appears to have merged some of the ways but
> not
> others. In my example is seems as if merging has been prevented when
> the original ways have conflicting tags (maybe just the name=)
>
> Given that it isn't possible to differentiate the multiple outer ways
> when passed in from multiPolygon, why doesn't it just pass in the
> joined way that will be passed to the 'polygons' processing.
>
> Also, assuming that later processing is joining some of these parts,
> what stops it joining them all.
>
> I can give you details of my example if required, but just having:
>
> mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
>
> in 'lines' then looking for consecutive identical 'Way generated
> from...' output and checking that there is only 1 output polygon will
> yield a lot.
>
> Another difference between closed ways and multi-polygons is that
> with
> a closed way the object is passed through the rules of 'lines'
> concatenated with 'polygons' and all the facilties of stopping after
> a
> match/continue/with_actions work in a nice way, whereas with a multi
> -polygon, even if it matches in 'lines', it is passed through
> 'polygons' as well; so extra conditions will is needed in 'polygons'
> to
> determine if matched in 'lines'
>
> Regards
> Ticker
>
> ___
> 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] closed ways and multi-polygon relations
Hi Ticker,
I don't understand what you expect here. The ways with tag mkgmap:mp_created
are the result of the joining process. Normally they are closed.
Is the one way that is reported a part of a broken MP?
Maybe you expect that the members of a MP rel do also have a special tag?
That would be something that you have to do in the relations style file.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 22. November 2018 17:03
An: mkgmap development
Betreff: [mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd
I'd hoped and expected that all polygons were fed into the 'lines'
style processing in a similar manner, regardless of their origin as
either a closed OSM way or generated by multiPolygonRelation. This
would allow simple testing using just 'is_closed()=true' to effect
lines around polygons if required.
Instead I find that, for a few examples I've looked at in detail, for
each outer way in a relation a way is passed into 'lines'. They all
have identical tags (from the relation) and is_closed()=false. It is
difficult to determine if these correspond directly to the ways in the
relation.
In the generated map, the line around the area might be in multiple
segments, so some logic appears to have merged some of the ways but not
others. In my example is seems as if merging has been prevented when
the original ways have conflicting tags (maybe just the name=)
Given that it isn't possible to differentiate the multiple outer ways
when passed in from multiPolygon, why doesn't it just pass in the
joined way that will be passed to the 'polygons' processing.
Also, assuming that later processing is joining some of these parts,
what stops it joining them all.
I can give you details of my example if required, but just having:
mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
in 'lines' then looking for consecutive identical 'Way generated
from...' output and checking that there is only 1 output polygon will
yield a lot.
Another difference between closed ways and multi-polygons is that with
a closed way the object is passed through the rules of 'lines'
concatenated with 'polygons' and all the facilties of stopping after a
match/continue/with_actions work in a nice way, whereas with a multi
-polygon, even if it matches in 'lines', it is passed through
'polygons' as well; so extra conditions will is needed in 'polygons' to
determine if matched in 'lines'
Regards
Ticker
___
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
[mkgmap-dev] closed ways and multi-polygon relations
Hi Gerd
I'd hoped and expected that all polygons were fed into the 'lines'
style processing in a similar manner, regardless of their origin as
either a closed OSM way or generated by multiPolygonRelation. This
would allow simple testing using just 'is_closed()=true' to effect
lines around polygons if required.
Instead I find that, for a few examples I've looked at in detail, for
each outer way in a relation a way is passed into 'lines'. They all
have identical tags (from the relation) and is_closed()=false. It is
difficult to determine if these correspond directly to the ways in the
relation.
In the generated map, the line around the area might be in multiple
segments, so some logic appears to have merged some of the ways but not
others. In my example is seems as if merging has been prevented when
the original ways have conflicting tags (maybe just the name=)
Given that it isn't possible to differentiate the multiple outer ways
when passed in from multiPolygon, why doesn't it just pass in the
joined way that will be passed to the 'polygons' processing.
Also, assuming that later processing is joining some of these parts,
what stops it joining them all.
I can give you details of my example if required, but just having:
mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'}
in 'lines' then looking for consecutive identical 'Way generated
from...' output and checking that there is only 1 output polygon will
yield a lot.
Another difference between closed ways and multi-polygons is that with
a closed way the object is passed through the rules of 'lines'
concatenated with 'polygons' and all the facilties of stopping after a
match/continue/with_actions work in a nice way, whereas with a multi
-polygon, even if it matches in 'lines', it is passed through
'polygons' as well; so extra conditions will is needed in 'polygons' to
determine if matched in 'lines'
Regards
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Andrzej,
there is a comment in style file relations :
# apply way { add name='${name}' }
but it seems this syntax was never implemented. I can try to add that, too.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Donnerstag, 22. November 2018 10:57
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Gerd,
I think it would be better to have something like apply_first_way. See
for example these relations, where first member is a point:
https://www.openstreetmap.org/relation/1699620
https://www.openstreetmap.org/relation/254686
--
Best regards,
Andrzej
___
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] Add a POI to the start of a relation (route:mtb)
Hi Gerd, I think it would be better to have something like apply_first_way. See for example these relations, where first member is a point: https://www.openstreetmap.org/relation/1699620 https://www.openstreetmap.org/relation/254686 -- 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] Add a POI to the start of a relation (route:mtb)
Hi Andreas,
sorry, it would work but it would require a lot of work since a normal style
function only knows either the relation or the member, not both.
While looking at this I noticed the apply_once action. I think it is almost
what we need, so I implemented an apply_first action with the attached patch.
As the name suggests it is only executed for the first member.
A binary is here:
http://files.mkgmap.org.uk/detail/438
Please let me know if that works for you, if yes, I'll add some documentation.
Gerd
Von: mkgmap-dev im Auftrag von
andreas.schmidt.hetschb...@t-online.de
Gesendet: Mittwoch, 21. November 2018 15:24
An: mkgmap-dev; Development list for mkgmap
Betreff: Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Gerd,
type=route & route=mtb
{ apply mem_pos() = [first,x,last]
{
set ...
}
}
Could do the job.
Andreas
Gesendet von Mail für Windows 10
Von: Gerd Petermann
Gesendet: Mittwoch, 21. November 2018 11:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
Hi Andreas,
I still don't see where to handle this in mkgmap. A way can be the member of
several route relations.
It might be the start of one and the end of two others, or vice versa. When
the route describes a closed ring it would be start and end.
I don't want to handle those cases in the java code, this should be done in
the style.
So, maybe a style function mem_pos() could help? I could be used in a rule
like this
type=route & route=mtb
{ apply mem_pos() = 1
{
set ...
}
}
Or maybe the style function should return "first", "somewhere", "last" ?
Gerd
--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
apply_first.patch
Description: apply_first.patch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
