Re: [mkgmap-dev] Tagging restaurants and categories
Thanks all, I see this in the default style file and now have the answer:
need a change to the style. I see the comments in the file - this
satisfies the query.
Looking through my locale and the categories available on my Garmin, the
bagel/donut shops are the only one that seems to be an outlier. I've
always known this area has a lot of health nuts and for the longest time
the only Dunkin' Donuts went out of business, but there is definitely one
in town once more among a lot of other independent shops, just weird none
show up.
I suppose I'll leave this up to whoever whether to change the default or
not. I only know of two chain restaurants that also get binned into
fast_food but people in the USA may or may not consider them "fast food
quality" that may or may not be better to show up in their category...
Thanks.
On Tue, 3 Mar 2020, Pinns UK wrote:
Date: Tue, 3 Mar 2020 08:50:02 +
From: Pinns UK
Reply-To: Development list for mkgmap
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Tagging restaurants and categories
Multiple tags seem to occur more frequently in OSM , particularly in
polygons and to a lesser extent in lines. Luxembourg is a good example.
I've had to adapt my style to ensure woods were plotted when combined with
another tag.
ie
Polygons
combining natural , landuse , leisure etc
natural=wood & landuse=grass
leisure & natural / landuse
leisure=nature_reserve and landuse=forest
Lines
waterway=stream & boundary=administrative
I'm not sure how the default style deals with this? and perhaps it doesn't
matter.
regards
Nick
On 03/03/2020 08:12, Ticker Berkin wrote:
Hi all
It relatively easy for a style to generate multiple POI for the same
point, in this case one "Fast Food" and one "Bagel/Donut".
The default style doesn't do this, but it makes a choice about which is
shown in this and similar cases, carefully commented to show how to get
the other:
# Have the following 2 lines here rather than after cuisine=... so
that, for amenity=fast_food, cuisine is ignored
amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
amenity=fast_food [0x2a07 resolution 24]
...
cuisine=bagel | cuisine=donut
[0x2a0d resolution 24]
...
Have the following 2 lines here rather than before cuisine=... so that,
for amenity=fast_food, cuisine is respected
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WARNING: All HTML emails get auto deleted. DO NOT SEND HTML MAIL.
WARNING: Emails with large typo counts/spelling errors will also be deleted.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, nice :) Committed with r4461, with small changes. This even allows to change the test case for lamp4 from expected="?" to expected="2" (ON). reg. the distance calculations: I don't remember the details and maybe all is wrong. See svn log for r : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap= and search the archives for "Great Britain National Grid". The math behind projections and distance formulas is too complex for me. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 3. März 2020 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Patch attached: - inherits your is_in-function_v14.patch - adds Math.round to Coord.makeBetweenPoint(); Is this how you indented? - removes IsInUtil.insidePolygon() and changes callers to use isPointInShape() - adds ON tolerance to isPointInShape() - I couldn't work out how to do this with the winding algo, so changed it to crossing-point, which is fine for mkgmap polygons. - add some more tolerances to isLineInShape - isLineInShape had comment: // it is unlikely but not impossible that pTest is on boundary :( and it returned the wrong result if it was. This contributed to the difficulties with b14 (and b19). I've fixed it and, I think, improved and simplified the running status setting - fix spelling of rhumLine to rhumbLine There are still a couple of places that have complicated distance calculation and point insertion using, bearings, rhumbline, meter conversion but I don't think it is worth re-implementing them for this. I'm slightly surprised how much use there is of bearing/rhumbLine/Mercator projection calculations. I think real distance/metre calcs should be "great circle" and internal poly/line chopping, testing etc should be high-precision polar coords. Ticker On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote: > Hi Ticker, > > if you see a way to change the algo just do it. > I've just noticed that I forgot to commit a change in > Coord.makeBetweenPoint(). > This routine should use Math.round. Will reduce the error by 50%, > right? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 27. Februar 2020 20:24 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Looking at the distance calculations to compare with EPS (ie very > small), wouldn't it be much simpler and clearer just to calculate it > as > highPrecisionSquared units, not bothering with degrees/radians, rhumb > -line, metre conversion etc. Then EPS would be 4. > > Then, considering IsInUtil.insidePolgon and can it be changed to have > some tolerance and maybe changing the interface to return IN/ON/OUT, > it > looks like it will stop, returning onBoundary, if there is a polygon > segment that 'aims at' the point. > > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Patch attached:
- inherits your is_in-function_v14.patch
- adds Math.round to Coord.makeBetweenPoint(); Is this how you
indented?
- removes IsInUtil.insidePolygon() and changes callers to use
isPointInShape()
- adds ON tolerance to isPointInShape() - I couldn't work out how to do
this with the winding algo, so changed it to crossing-point, which is
fine for mkgmap polygons.
- add some more tolerances to isLineInShape
- isLineInShape had comment:
// it is unlikely but not impossible that pTest is on boundary :(
and it returned the wrong result if it was. This contributed to the
difficulties with b14 (and b19). I've fixed it and, I think, improved
and simplified the running status setting
- fix spelling of rhumLine to rhumbLine
There are still a couple of places that have complicated distance
calculation and point insertion using, bearings, rhumbline, meter
conversion but I don't think it is worth re-implementing them for this.
I'm slightly surprised how much use there is of
bearing/rhumbLine/Mercator projection calculations. I think real
distance/metre calcs should be "great circle" and internal poly/line
chopping, testing etc should be high-precision polar coords.
Ticker
On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if you see a way to change the algo just do it.
> I've just noticed that I forgot to commit a change in
> Coord.makeBetweenPoint().
> This routine should use Math.round. Will reduce the error by 50%,
> right?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 20:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Looking at the distance calculations to compare with EPS (ie very
> small), wouldn't it be much simpler and clearer just to calculate it
> as
> highPrecisionSquared units, not bothering with degrees/radians, rhumb
> -line, metre conversion etc. Then EPS would be 4.
>
> Then, considering IsInUtil.insidePolgon and can it be changed to have
> some tolerance and maybe changing the interface to return IN/ON/OUT,
> it
> looks like it will stop, returning onBoundary, if there is a polygon
> segment that 'aims at' the point.
>
> Ticker
Index: src/uk/me/parabola/imgfmt/app/Coord.java
===
--- src/uk/me/parabola/imgfmt/app/Coord.java (revision 4460)
+++ src/uk/me/parabola/imgfmt/app/Coord.java (working copy)
@@ -56,6 +56,7 @@
public static final int DELTA_SHIFT = HIGH_PREC_BITS - 24;
private static final int MAX_DELTA = 1 << (DELTA_SHIFT - 2); // max delta abs value that is considered okay
private static final long FACTOR_HP = 1L << HIGH_PREC_BITS;
+ private static final int HIGH_PREC_UNUSED_BITS = Integer.SIZE - HIGH_PREC_BITS;
public static final double R = 6378137.0; // Radius of earth at equator as defined by WGS84
public static final double U = R * 2 * Math.PI; // circumference of earth at equator (WGS84)
@@ -516,6 +517,16 @@
}
/**
+ * Distance to other point in high precision squared units
+ */
+ public long distanceInHighPrecSquared(Coord other) {
+ int dLatHp = other.getHighPrecLat() - getHighPrecLat();
+ int dLonHp = other.getHighPrecLon() - getHighPrecLon();
+ dLonHp = (dLonHp << HIGH_PREC_UNUSED_BITS) >> HIGH_PREC_UNUSED_BITS; // fix wrap-around earth
+ return (long)dLatHp * dLatHp + (long)dLonHp * dLonHp;
+ }
+
+ /**
* Calculate point on the line this->other. If d is the distance between this and other,
* the point is {@code fraction * d} metres from this.
* For small distances between this and other we use a flat earth approximation,
@@ -525,15 +536,15 @@
public Coord makeBetweenPoint(Coord other, double fraction) {
int dlatHp = other.getHighPrecLat() - getHighPrecLat();
int dlonHp = other.getHighPrecLon() - getHighPrecLon();
- if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100 ){
+ if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100) {
// distances are rather small, we can use flat earth approximation
- int latHighPrec = (int) (getHighPrecLat() + dlatHp * fraction);
- int lonHighPrec = (int) (getHighPrecLon() + dlonHp * fraction);
+ int latHighPrec = (int)Math.round(getHighPrecLat() + dlatHp * fraction);
+ int lonHighPrec = (int)Math.round(getHighPrecLon() + dlonHp * fraction);
return makeHighPrecCoord(latHighPrec, lonHighPrec);
}
double brng = this.bearingToOnRhumbLine(other, true);
double dist = this.distance(other) * fraction;
- return this.destOnRhumLine(dist, brng);
+ return this.destOnRhumbLine(dist, brng);
}
@@ -763,7 +774,7 @@
* @param brng bearing in degrees
* @return a new Coord instance
*/
- public Coord destOnRhumLine(double dist, double brng){
+ public Coord destOnRhumbLine(double dist, double brng){
double distRad = dist / R; // angular distance in radians
Re: [mkgmap-dev] Tagging restaurants and categories
Multiple tags seem to occur more frequently in OSM , particularly in
polygons and to a lesser extent in lines. Luxembourg is a good example.
I've had to adapt my style to ensure woods were plotted when combined
with another tag.
ie
*Polygons*
combining natural , landuse , leisure etc
natural=wood & landuse=grass
leisure & natural / landuse
leisure=nature_reserve and landuse=forest
*Lines*
waterway=stream & boundary=administrative
I'm not sure how the default style deals with this and perhaps it
doesn't matter.
regards
Nick
On 03/03/2020 08:12, Ticker Berkin wrote:
Hi all
It relatively easy for a style to generate multiple POI for the same
point, in this case one "Fast Food" and one "Bagel/Donut".
The default style doesn't do this, but it makes a choice about which is
shown in this and similar cases, carefully commented to show how to get
the other:
# Have the following 2 lines here rather than after cuisine=... so
that, for amenity=fast_food, cuisine is ignored
amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
amenity=fast_food [0x2a07 resolution 24]
...
cuisine=bagel | cuisine=donut
[0x2a0d resolution 24]
...
Have the following 2 lines here rather than before cuisine=... so that,
for amenity=fast_food, cuisine is respected
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]
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] Tagging restaurants and categories
Hi all
It relatively easy for a style to generate multiple POI for the same
point, in this case one "Fast Food" and one "Bagel/Donut".
The default style doesn't do this, but it makes a choice about which is
shown in this and similar cases, carefully commented to show how to get
the other:
# Have the following 2 lines here rather than after cuisine=... so
that, for amenity=fast_food, cuisine is ignored
amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
amenity=fast_food [0x2a07 resolution 24]
...
cuisine=bagel | cuisine=donut
[0x2a0d resolution 24]
...
Have the following 2 lines here rather than before cuisine=... so that,
for amenity=fast_food, cuisine is respected
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
