logo separator

[mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Fri Dec 20 12:49:56 GMT 2019

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 at lists.mkgmap.org.uk> im Auftrag
> von svn commit <svn at mkgmap.org.uk>
> Gesendet: Mittwoch, 18. Dezember 2019 09:24
> An: mkgmap-svn at lists.mkgmap.org.uk; mkgmap-dev at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list