Re: [mkgmap-dev] Branch is_in ready for a first test

Arndt Röhrig Sat, 11 Jan 2020 03:04:07 -0800

Good morning,

so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great.

I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc.

Thank you all for this work!

Problem #1:

is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either.

I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea?

https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png

Problem, #2:

r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON

https://speichenkarte.de/88002007.osm.pbf

greetings

Arndt

Gerd Petermann < [email protected]> hat am 10. Januar 2020 um 12:07 geschrieben:

Hi Ticker,

thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412

Gerd

________________________________________

Von: mkgmap-dev < [email protected]> im Auftrag von Ticker Berkin < [email protected]>

Gesendet: Freitag, 10. Januar 2020 11:29

An: Development list for mkgmap

Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

Here is patch that sets isLineRule in the package on the augmentsWith

call.

I've also used default method for the augmentsWith... in Rule, Op,

OsmConverter and backed out the changes that have now become

unnecessary.

Ticker

On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote:

Hi Ticker,

yes, it would probably be better to know if the function is for a

polyline or polygon. A patch would be welcomed.

And yes, the expected result for the case you describe is not yet

clear. See b13 and b14 in my example file.

Gerd

________________________________________

Von: mkgmap-dev < [email protected]> im Auftrag

von Ticker Berkin < [email protected]>

Gesendet: Freitag, 10. Januar 2020 09:59

An: Development list for mkgmap

Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

I think the logic still needs to know if it is handling a closed way

as

a polygon rule or as a line rule.

Firstly to be able to correctly handle the case where the rule.way

runs

around a hole in the target.polygon - all of the rule.line is in the

target, but only part of the rule.polygon is in the target.

Also there might be different method keywords for the two. For

polygon

rules, "any" and "all" are adequate, but for line rules others might

be

required.

I've just svn updated the is_in branch. Is there still work to do on

non-closed ways?

Otherwise amazing.

Ticker

On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:

Hi all,

the branch version r4408 implements the style function is_in with

three parameters tag-key,tag-value,method

- tag-key can be something like landuse or natural or amenity

- tag-value would be the expected value for that tag-key

- method has to be "any" or "all".

Example usage in lines:

# no cycling within a cemetery

highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add

bicycle=dismount}

Before any style rule is evaluated the function evaluates the list

of

all ways found in the input file. When a way matches the given tag

(key+value) and is closed and complete the shape geometry is stored

in a spatial index.

With the current implementation this index is created for

appearance

of the is_in function in a style rule (subject to optimization)

When the style function is called it retrieves the stored shape(s)

which intersect the boundary of the element.

If none is found "false" is returned.

If there are multiple such shapes the are merged where possible, so

that overlapping or touching shapes are combined to a single shape

which may include holes.

The list of (outer) shapes is then tested one after the other until

one shape is found which either contains the element completely or

-

when "any" is used as method - partially. If none is found the

value

"false" is returned.

If a match is found and the combined shapes have holes, a final

test

is done to find out if the element is within the hole.

If method "any" is used and the shape is completey within one hole

"false" is returned.

If method "all" is used and the shape is partly within one hole

"false" is returned.

If we get here true is "returned"

I've also slightly changed the behaviour of the LocationHook and

the

ResidentialHook. The results should be a bit more predictable now

as

searches are done with higher precsion. Still, both try to find a

nearby boundary(shape) if none is found at the exact position.

The ResidentialHook is now automatically disabled when the style

doesn't use mkgmap:residential anywhere.

TODO:

- various possible special cases need more testing

- maybe add more methods for cases where parts of the tested

element

touch the boundary of the shape.

- tuning

- unit tests

As always with branch version the binary can be found at the bottom

of the download page.

http://www.mkgmap.org.uk/download/mkgmap.html

I've tested this with the example file posted before, accept for

b18

all cases work as expected.

Gerd

_______________________________________________

mkgmap-dev mailing list

[email protected]

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________

mkgmap-dev mailing list

[email protected]

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________

mkgmap-dev mailing list

[email protected]

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Branch is_in ready for a first test

Reply via email to