Test cases for possible is-in-hook
Hi all, this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-revert-changes-from-r4397-is-in-... Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma? Gerd P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.
Hi Gerd This is looking more and more complicated with: 1/ High cost of total accuracy 2/ Multi-polygons haven't been processed at the time the hook attempts to set the tag? 3/ holes due to multi-polygons 4/ lines crossing polygon boundaries where different attribute are required on either side 5/ some uses of this feature might not want total accuracy, just something close by. What do you think of the idea of making this a style function? 1/ The cost can be delayed until the rule is evaluated 2/ Following on from this, if the requirement is only testing, say, a way being in a polygon, the unnecessary work of calculating is-in for all polygons and points is avoided 3/ The function invoked from a rule itself can indicate, with a parameter, what sort of algorithm/accuracy is required 4/ multi-polygon processing has happened at this point (has it?) Thinking about total accuracy for polygons, if there was a function that subtracts a polygon from another, then the change in area will give the answer about full/partial/no inclusion. Ticker On Sat, 2019-12-21 at 09:02 +0000, Gerd Petermann wrote:
Hi all,
this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-re vert-changes-from-r4397-is-in-landuse-option-tp5953750p5954041.html Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma?
Gerd
P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all In a recent svn commit message, Gerd wrote:
check both lines and polygons with the same method As expected performance is poor when compared to ResidentialHook
If some users were happy with the approximations used by the --residential-hook implementation, I see no reason why the same algorithm shouldn't be invoked under the control of the accuracy parameter, eg:
highway=path & is_in(landuse, residential, approx) {...} [...]
Going back to the test cases, just considering lines and their relationship to polygons and exact/maximum precision, possibilities are: 1/ all of the line is outside the polygon 2/ some of the line is outside and the rest touches or runs along the polygon edge 3/ all of the line runs along the polygon edge 4/ some of the line is inside and the rest touches or runs along. 5/ all of the line is inside the polygon 6/ some is inside and some outside the polygon. Obviously some point is on the polygon edge but we don't care if runs along the edge. If an apex of the line touches the edge of the polygon (from either inside or outside) or an apex of the polygon touches the line (again from either side) then this should be considered an 'on' point The questions that it seems meaningful to ask (via the accuracy parameter) are: a) all-in, ie. 5/ b) all-in-or-on, ie. 3/ or 4/ or 5/ c) all-on, ie 3/ d) any-in, ie 4/ or 5/ or 6/ For some of these cases the inverse is meaningful and useful:
barrier=wall & is_in(building, castle, all-on)=false [0x17] ie: don't render a wall that follows the edge of a castle
@all, please say if you see the need for other tests and which of 1/ .. 6/ they should return 'true' for. It might be too complex to spot the all the cases enumerate earlier, so this is not a promise of the final functionality. Also, I'm not saying these should be the final keywords - suggestions welcome. Ticker On Sat, 2019-12-21 at 09:02 +0000, Gerd Petermann wrote:
Hi all,
this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-re vert-changes-from-r4397-is-in-landuse-option-tp5953750p5954041.html Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma?
Gerd
P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I think Tickers list is correct, but I also agree that we may not reach that accuracy. One of the problems with these geometry calculations is that rounding errors make it rather impossible to distinuish between "exactly on boundary" and "very close to boundary". Of course, if a way shares a node with the boundary we can say "exactly on" but if not we have to use an epsilon of at least a few centimers. Reg. performance: This is subject to tuning, my first goal is to find an algo which calculates the wanted results with an acceptable error rate. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 3. Januar 2020 11:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Test cases for possible is-in-hook Hi all In a recent svn commit message, Gerd wrote:
check both lines and polygons with the same method As expected performance is poor when compared to ResidentialHook
If some users were happy with the approximations used by the --residential-hook implementation, I see no reason why the same algorithm shouldn't be invoked under the control of the accuracy parameter, eg:
highway=path & is_in(landuse, residential, approx) {...} [...]
Going back to the test cases, just considering lines and their relationship to polygons and exact/maximum precision, possibilities are: 1/ all of the line is outside the polygon 2/ some of the line is outside and the rest touches or runs along the polygon edge 3/ all of the line runs along the polygon edge 4/ some of the line is inside and the rest touches or runs along. 5/ all of the line is inside the polygon 6/ some is inside and some outside the polygon. Obviously some point is on the polygon edge but we don't care if runs along the edge. If an apex of the line touches the edge of the polygon (from either inside or outside) or an apex of the polygon touches the line (again from either side) then this should be considered an 'on' point The questions that it seems meaningful to ask (via the accuracy parameter) are: a) all-in, ie. 5/ b) all-in-or-on, ie. 3/ or 4/ or 5/ c) all-on, ie 3/ d) any-in, ie 4/ or 5/ or 6/ For some of these cases the inverse is meaningful and useful:
barrier=wall & is_in(building, castle, all-on)=false [0x17] ie: don't render a wall that follows the edge of a castle
@all, please say if you see the need for other tests and which of 1/ .. 6/ they should return 'true' for. It might be too complex to spot the all the cases enumerate earlier, so this is not a promise of the final functionality. Also, I'm not saying these should be the final keywords - suggestions welcome. Ticker On Sat, 2019-12-21 at 09:02 +0000, Gerd Petermann wrote:
Hi all,
this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-re vert-changes-from-r4397-is-in-landuse-option-tp5953750p5954041.html Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma?
Gerd
P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.
_______________________________________________ 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, I would define the 6 cases in Tickers given (with the explained handling of apexes) as followed: a) all-in > 4/ 5/ b) all-in-or-on > 3/ 4/ 5/ c) all-on > 3/ d) any-in > 4/ 5/ 6/ Outside > 1/ 2/ These options are impressively complex, I can´t imagine any further yet. Jan
Hi Jan OK, but Outside needs to be expressed in the inverse, ie e) any-in-or-on > 3/ 4/ 5/ 6/ and then tested as ... is_in(tag,val,any-in-or-on)=false ... because the logic will look for all correctly tagged polygons nearby and then check each in turn to see if it matches the accuracy requirements and stop with 'true' if it does, returning 'false' if none match. So, if there were two matching areas, the line could be outside one and inside the other, and 'outside' would return true. The cases 1/ to 6/ would be more logically expressed with 3 flags: IN, ON, OUT set as the algorithm examines the relationship of the line segments with the polygon segments, then we have: a) all-in IN and not (ON or OUT) Jan's alternative IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON Ticker On Fri, 2020-01-03 at 23:49 +0100, jan meisters wrote:
Hi all,
I would define the 6 cases in Tickers given (with the explained handling of apexes) as followed:
a) all-in > 4/ 5/ b) all-in-or-on > 3/ 4/ 5/ c) all-on > 3/ d) any-in > 4/ 5/ 6/ Outside > 1/ 2/
These options are impressively complex, I can´t imagine any further yet.
Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, sorry for the slow progress. I've a bad cold since Christmas and I amstruggling with rounding errors and edge cases. I came to the conclusion that the rounding errors (esp. those from 32 bit OSM precision to mkgmap 30 bit "high precision" ) make it impossible to get correct resuls whenever a node is very close to a line segment. When JOSM shows this node being outside or on boundary of a given polygon, the rounding may place it inside (or vice versa). You can think of a halo of maybe 5 cm around the objects displayed in OSM where you cannot trust the results. The attached file contains an example. I've created building b18 in JOSM by drawing a building next to the residential area. Then I used N (Move node onto way) with the nodes next to the area. Finally I've unglued the building again and removed the nodes from the residential area. Result in JOSM is that one segment of b18 is exactly on the boundary of the residential area. Now, after the rounding, the lower left corner of the building is moved a tiny bit up and the the lower right corner is moved a tiny bit down relative to the residential area. As a result, the standard insideness calculations find a crossing segment and thus calculate a 6 in Tickers list. Results can change when you select both ways and move them to a different position. Fortunately this doesn't happen often in real OSM data, typically objects which are that close to each other share nodes, but the exceptions are very often along a highway. Anyway, I've decided to ignore the wrong results created by the rounding for now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 4. Januar 2020 12:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Test cases for possible is-in-hook Hi Jan OK, but Outside needs to be expressed in the inverse, ie e) any-in-or-on > 3/ 4/ 5/ 6/ and then tested as ... is_in(tag,val,any-in-or-on)=false ... because the logic will look for all correctly tagged polygons nearby and then check each in turn to see if it matches the accuracy requirements and stop with 'true' if it does, returning 'false' if none match. So, if there were two matching areas, the line could be outside one and inside the other, and 'outside' would return true. The cases 1/ to 6/ would be more logically expressed with 3 flags: IN, ON, OUT set as the algorithm examines the relationship of the line segments with the polygon segments, then we have: a) all-in IN and not (ON or OUT) Jan's alternative IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON Ticker On Fri, 2020-01-03 at 23:49 +0100, jan meisters wrote:
Hi all,
I would define the 6 cases in Tickers given (with the explained handling of apexes) as followed:
a) all-in > 4/ 5/ b) all-in-or-on > 3/ 4/ 5/ c) all-on > 3/ d) any-in > 4/ 5/ 6/ Outside > 1/ 2/
These options are impressively complex, I can´t imagine any further yet.
Jan _______________________________________________ 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
participants (4)
-
Gerd Petermann -
Gerd Petermann
-
jan meisters -
Ticker Berkin