Commit r4398: revert changes from r4397 (--is-in-landuse option)
Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398
Hi all, I think I have now the needed methods to be able to distuingish if a given node is inside, outside or "on boundary" of a polygon. In (1) Ticker suggested to use these rules to determine what tag the hook should add either IN, OUT, or STRADDLE as a tag value. The current implementation in ResidentialHook adds either no tag (meaning outside) or a tag with the value "yes" or the name of the found residential area. The typical rule to use this tag would be mkgmap:residential=* {do something} I think we should NOT add the tag with a value OUT, else the above rule will fail. On the other hand, I assume that nobody use a rule like mkgmap:residential=* & mkgmap:residential!=yes {do something with the name contained in mkgmap:residential} I think it was not a good idea to use the name, I used it for debugging. Open question: Should we really just count points? Assume you have a U-shaped cemetery and a highway=footway with just two points starts inside the left upper part and ends inside the right upper part. Most of the way would be outside but the points are inside the cemetery. No idea how often this happens, but the result would be "IN" with Tickers rules. Even when you add (barrier=gate) nodes on the boundaries of the cemetery the result is still "IN" I woud call this result wrong and expect a value like STRADDLE. Gerd (1) http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-document-new-optio... ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von svn commit <svn@mkgmap.org.uk> Gesendet: Mittwoch, 18. Dezember 2019 09:24 An: mkgmap-svn@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option) Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Given the complexity and cpu cost of calculating this, the various questions, hence answers possible and it has to be done for all elements if the --is-in option is given what about making it a function instead. This means that it only needs to be computed for elements where the answer matters and, as a parameter, the question about what the required is-in means can be asked. eg, in points: if building=church and is-in('landuse', 'cemetery') {add name='Chapel of Rest'} in lines: if highway=* and is-in('landuse', 'cemetary', 'fully') {add bicycle=no} etc. Above are just approximations of how the parameters might work. The various levels of is-in that might be required should be considered, as per Gerd's comments. For some of the examples that have been given for use of this facility, I feel they should really be solved by accurate tagging. @gerd Although it looked like it, I didn't really intend that elements were tagged with NO if no part was within the polygon. Ticker On Fri, 2019-12-20 at 10:43 +0000, Gerd Petermann wrote:
Hi all,
I think I have now the needed methods to be able to distuingish if a given node is inside, outside or "on boundary" of a polygon. In (1) Ticker suggested to use these rules to determine what tag the hook should add either IN, OUT, or STRADDLE as a tag value. The current implementation in ResidentialHook adds either no tag (meaning outside) or a tag with the value "yes" or the name of the found residential area.
The typical rule to use this tag would be mkgmap:residential=* {do something}
I think we should NOT add the tag with a value OUT, else the above rule will fail. On the other hand, I assume that nobody use a rule like mkgmap:residential=* & mkgmap:residential!=yes {do something with the name contained in mkgmap:residential} I think it was not a good idea to use the name, I used it for debugging.
Open question: Should we really just count points? Assume you have a U-shaped cemetery and a highway=footway with just two points starts inside the left upper part and ends inside the right upper part. Most of the way would be outside but the points are inside the cemetery. No idea how often this happens, but the result would be "IN" with Tickers rules. Even when you add (barrier=gate) nodes on the boundaries of the cemetery the result is still "IN" I woud call this result wrong and expect a value like STRADDLE.
Gerd
(1) http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-documen t-new-option-is-in-landuse-value-value-tp5953495p5953703.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von svn commit <svn@mkgmap.org.uk> Gesendet: Mittwoch, 18. Dezember 2019 09:24 An: mkgmap-svn@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is -in-landuse option)
Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019
revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work.
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 _______________________________________________ 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
Hi all, attached is an OSM file with various test cases. Assume we want to get the result for landuse=residential. Please load it in JOSM and search for expected=in or expected=out or expected=straddle and finally expected="?" and let me know as soon as possible if you don't agree with anything. (each case has a different name for the object to be tested. The cases with "?" are special, I think b9 and b10 are not important, but the others are very usual in real OSM data. The existing ResidentialHook would add mkgmap:residential to b13, b14 and w26. @Ticker: The residential areas around b13 and b14 show the special case with multipolygons. The hook probably "sees" something like the b13 example when looking at b14 because the multipolygons are cut into pieces without holes before the hook is executed. @all: Would be very good to get some feedback on this, even if you think that you don't need the hook for your style. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 20. Dezember 2019 13:49 An: mkgmap development Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option) Hi Given the complexity and cpu cost of calculating this, the various questions, hence answers possible and it has to be done for all elements if the --is-in option is given what about making it a function instead. This means that it only needs to be computed for elements where the answer matters and, as a parameter, the question about what the required is-in means can be asked. eg, in points: if building=church and is-in('landuse', 'cemetery') {add name='Chapel of Rest'} in lines: if highway=* and is-in('landuse', 'cemetary', 'fully') {add bicycle=no} etc. Above are just approximations of how the parameters might work. The various levels of is-in that might be required should be considered, as per Gerd's comments. For some of the examples that have been given for use of this facility, I feel they should really be solved by accurate tagging. @gerd Although it looked like it, I didn't really intend that elements were tagged with NO if no part was within the polygon. Ticker On Fri, 2019-12-20 at 10:43 +0000, Gerd Petermann wrote:
Hi all,
I think I have now the needed methods to be able to distuingish if a given node is inside, outside or "on boundary" of a polygon. In (1) Ticker suggested to use these rules to determine what tag the hook should add either IN, OUT, or STRADDLE as a tag value. The current implementation in ResidentialHook adds either no tag (meaning outside) or a tag with the value "yes" or the name of the found residential area.
The typical rule to use this tag would be mkgmap:residential=* {do something}
I think we should NOT add the tag with a value OUT, else the above rule will fail. On the other hand, I assume that nobody use a rule like mkgmap:residential=* & mkgmap:residential!=yes {do something with the name contained in mkgmap:residential} I think it was not a good idea to use the name, I used it for debugging.
Open question: Should we really just count points? Assume you have a U-shaped cemetery and a highway=footway with just two points starts inside the left upper part and ends inside the right upper part. Most of the way would be outside but the points are inside the cemetery. No idea how often this happens, but the result would be "IN" with Tickers rules. Even when you add (barrier=gate) nodes on the boundaries of the cemetery the result is still "IN" I woud call this result wrong and expect a value like STRADDLE.
Gerd
(1) http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-documen t-new-option-is-in-landuse-value-value-tp5953495p5953703.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von svn commit <svn@mkgmap.org.uk> Gesendet: Mittwoch, 18. Dezember 2019 09:24 An: mkgmap-svn@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is -in-landuse option)
Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019
revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work.
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 _______________________________________________ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, great job! Concerning my english: I understand straddle as effectively outside, correct? Until now I only focussed on lines. In the samples every scenario of them looks good to me, if straddle=out. If not, hmm. For w26 i expect in. Attached is another example, stripped from OSM for residential also. By 4397 the whole track is rendered as in. With patched 4398 the line is split at the top west point of the residential llanduse and from there processed as in to the east. But I would expect it as completely out. (The original is here: https://www.openstreetmap.org/way/17937104, and I ask for allotments as in) Jan
Am 20.12.2019 um 19:56 schrieb Arndt Röhrig <arndt@speichenkarte.de>:
Hi Gerd,
with r4397 i used this:
mkgmap:lu:cemetery=* &! ((route_mtb=*|route_icn=*|route_ncn=*|route_lcn=*|route_rcn=*) | bicycle~'yes|official|designated|dismount|ok') {set rad=nein}
and this
highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-22 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 21-21 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-23 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 22-21 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue]
I think it´s nice, to expand the function mkgmap:lu:cemetery, so that some other polys (playground, military, deponie etc) work with this.
i don´t understand all mails, because my english is .....(:
Thank you for all the work you do!
best regards
Arndt
Gerd Petermann < gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> hat am 20. Dezember 2019 um 18:32 geschrieben:
Hi all,
attached is an OSM file with various test cases. Assume we want to get the result for landuse=residential. Please load it in JOSM and search for expected=in or expected=out or expected=straddle and finally expected="?" and let me know as soon as possible if you don't agree with anything. (each case has a different name for the object to be tested. The cases with "?" are special, I think b9 and b10 are not important, but the others are very usual in real OSM data. The existing ResidentialHook would add mkgmap:residential to b13, b14 and w26.
@Ticker: The residential areas around b13 and b14 show the special case with multipolygons. The hook probably "sees" something like the b13 example when looking at b14 because the multipolygons are cut into pieces without holes before the hook is executed.
@all: Would be very good to get some feedback on this, even if you think that you don't need the hook for your style.
Gerd
________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 20. Dezember 2019 13:49 An: mkgmap development Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)
Hi
Given the complexity and cpu cost of calculating this, the various questions, hence answers possible and it has to be done for all elements if the --is-in option is given what about making it a function instead.
This means that it only needs to be computed for elements where the answer matters and, as a parameter, the question about what the required is-in means can be asked.
eg, in points:
if building=church and is-in('landuse', 'cemetery') {add name='Chapel of Rest'}
in lines:
if highway=* and is-in('landuse', 'cemetary', 'fully') {add bicycle=no}
etc. Above are just approximations of how the parameters might work. The various levels of is-in that might be required should be considered, as per Gerd's comments.
For some of the examples that have been given for use of this facility, I feel they should really be solved by accurate tagging.
@gerd Although it looked like it, I didn't really intend that elements were tagged with NO if no part was within the polygon.
Ticker
On Fri, 2019-12-20 at 10:43 +0000, Gerd Petermann wrote:
Hi all, I think I have now the needed methods to be able to distuingish if a given node is inside, outside or "on boundary" of a polygon. In (1) Ticker suggested to use these rules to determine what tag the hook should add either IN, OUT, or STRADDLE as a tag value. The current implementation in ResidentialHook adds either no tag (meaning outside) or a tag with the value "yes" or the name of the found residential area. The typical rule to use this tag would be mkgmap:residential=* {do something} I think we should NOT add the tag with a value OUT, else the above rule will fail. On the other hand, I assume that nobody use a rule like mkgmap:residential=* & mkgmap:residential!=yes {do something with the name contained in mkgmap:residential} I think it was not a good idea to use the name, I used it for debugging. Open question: Should we really just count points? Assume you have a U-shaped cemetery and a highway=footway with just two points starts inside the left upper part and ends inside the right upper part. Most of the way would be outside but the points are inside the cemetery. No idea how often this happens, but the result would be "IN" with Tickers rules. Even when you add (barrier=gate) nodes on the boundaries of the cemetery the result is still "IN" I woud call this result wrong and expect a value like STRADDLE. Gerd (1) http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-documen <http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-documen> t-new-option-is-in-landuse-value-value-tp5953495p5953703.html ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von svn commit < svn@mkgmap.org.uk <mailto:svn@mkgmap.org.uk>> Gesendet: Mittwoch, 18. Dezember 2019 09:24 An: mkgmap-svn@lists.mkgmap.org.uk <mailto:mkgmap-svn@lists.mkgmap.org.uk>; mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is -in-landuse option) Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 <http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <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
participants (5)
-
Arndt Röhrig -
Gerd Petermann -
jan meisters -
svn commit -
Ticker Berkin