Re: [mkgmap-dev] Terraced/pixellated coastline with --precomp-sea

[Gerd Petermann]

Hi NopMap,

yes, docu is not correct here reg. the combination of options --precomp-sea and 
--generate-sea.
The precompiled sea data (sea.zip) from e.g. 
http://www.mkgmap.org.uk/download/mkgmap.html
doesn't contain type=multipilygon relations. It contains pbf files with 
(generated) ways with the tags
natural=sea or natural=land. I think that the creation of the data in sea.zip 
also doesn't involve any multipolygon
code. 
I think the docu is correct when you don't use --precomp-sea, but
the combinations
 --precomp-sea=sea.zip 
 --precomp-sea=sea.zip --generate-sea 
 --precomp-sea=sea.zip --generate-sea=multipolygon
all give the same result (single ways, no multipolygons).

I have no idea why WanMil (the initial coder) documented it that way.
I see no need to combine the two options, not even to set a different tag for 
land.
I assume it was done for backward compatibility.

Gerd


Von: mkgmap-dev  im Auftrag von NopMap 

Gesendet: Mittwoch, 22. Februar 2017 07:58:00
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Terraced/pixellated coastline with --precomp-sea

I definitely did not have a regular rule for natural=sea in my style. I need
to check whether there was a rule added by code in my tooling. (or in mkgmap
code)

Is the observation correct, that the SeaGenerator creates many simple
polygons, individually tagged as natural=sea, but not connected by a
multipolygon?

The command line description claims that the generator would use
multipolygons, but I believe that is not true.




--
View this message in context: 
http://gis.19327.n8.nabble.com/Terraced-pixellated-coastline-with-precomp-sea-tp5891553p5891833.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
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] To do: If-Then-Else

[Gerd Petermann]

Hi,

yes, Steve also noticed similar problems in the branch which also exist in 
trunk:
"It should be possible to do this:

boundary=administrative { set mkgmap:if:0001=1 }
mkgmap:if:0001=1 & admin_level<3 [0x1e resolution 12]
mkgmap:if:0001=1 & admin_level<5 [0x1d resolution 19]
mkgmap:if:0001!=1 & admin_level<3 [0x1f resolution 14]

But mkgmap fails here - when boundary=other,amdin_level=2, it should
trigger the third rule but it does not."

It seems that this error exists for a long time and is not easy to solve.
@Steve: Any updates on this? I got the impression that you already have a fix...

Gerd

Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Samstag, 18. Februar 2017 22:24:51
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] To do: If-Then-Else

Hi,

I have applied style-option patch v3 to if-then branch. I have noticed
following problems:
- tags created by style-option are treated as empty in conditionals,
- mkgmap gives warning about not used style-option, if it is used in
conditionals only,
- conditionals do not support function is_closed().

Following conditionals are always false:

if (mkgmap:option:aeroway=*) then
...
end

if (aeroway=runway & is_closed()=false) then
...
end

--
Best regards,
Andrzej
___
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] Terraced/pixellated coastline with --precomp-sea

[NopMap]

I definitely did not have a regular rule for natural=sea in my style. I need
to check whether there was a rule added by code in my tooling. (or in mkgmap
code)

Is the observation correct, that the SeaGenerator creates many simple
polygons, individually tagged as natural=sea, but not connected by a
multipolygon?

The command line description claims that the generator would use
multipolygons, but I believe that is not true.




--
View this message in context: 
http://gis.19327.n8.nabble.com/Terraced-pixellated-coastline-with-precomp-sea-tp5891553p5891833.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r3819: fix typo: use int instead of double for duplicate point detection

[svn commit]

Version mkgmap-r3819 was committed by gerd on Wed, 22 Feb 2017

fix typo: use int instead of double for duplicate point detection

No change in output expected, but maybe a minimal performance impact

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3819
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r3818: code improvements, no change in output expected

[svn commit]

Version mkgmap-r3818 was committed by gerd on Wed, 22 Feb 2017

code improvements, no change in output expected
- add constant Area PLANET 
- add some unit tests to detect problems with > 30 bits resolution
- initialize minlat/minlon etc. with Integer.MAX(MIN)_VALUE 

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3818
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[Greg Troxel]

Gerd Petermann  writes:

> I tried to create a patch for the rules which set mkgmap:unpaved using
> the wiki and taginfo:
> https://taginfo.openstreetmap.org/keys/surface#values
>
> One probem with surface is that we have so many values (taginfo lists
> 4844 different today), many of them typos or combinations like
> "ground;grass" or nonsense like "paved;unpaved" I guess many of the
> latter were produced by "connect ways" functions in OSM editors, so
> not fully intended.
>
> Anyhow, my impression is that it would be better to change the rule so
> that it checks the known paved surfaces and assumes that all others
> mean unpaved.  The current rules are quite old, it was introduced with
> r1425 and last changed with r1489.

[I know I'm late to replying; I left the thread unread until I had time
to read it and think a bit.]

One question is what should "unpaved" mean.  That probably depends on
car vs bicycle, and it seems the real issue is that the Garmin format
isn't expressive enough to allow routing to decide later what it wants
to use.  Thus we are having to map each road to a paved yes/no, road
class, and speed class.

Another way to look at this is to ask why we are representing unpaved
roads, and what the routing policy is we are trying to achieve by that.
In my case, for car, generally what I want is to not use rough roads
(dirt, and even cobblestone) unless it's more or less necessary, which
I'd define as being the only way or saving lots of time, even if I drive
10 km/h on the rough road.

So I would suggest that we think of the Garmin unpaved flag as a "this
is a road I want to avoid, as opposed to a road I don't want to avoid"
bit, and not be so fixated on what paved means.  That may mean different
people build images with different rules.

Then, I would think about what an optimal route is, and how to get the
Garmin unit to compute one when it thinks it is doing shortest time and
avoiding unpaved.  So I would use the unpaved flag for roads that you
really don't want to use, even if they save time, and use lower speed
classes for roads that you have a mild preference for avoiding.

Of course, I am not really sure how this would work.  And I realize it's
trickier with bicycle, where you care about pleasant/safe and time is
not so much the point. But I think the only way is to try to map some
utility function into inverse speed and let the Garmin unit try to
minimize time, since apparently there's no way to compute other utility
functions directly.  So basically if you'd rather ride 5 miles on road A
than 1 mile on road B, as an alternative to get someplace, set A's speed
to 5x B's speed, and then min time will do the right thing, even if you
get bad time estimates.




signature.asc
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

[Gerd Petermann]

Hi Ticker,

okay, I'll try to find out (again) why I decided to do the move only in 
low-prec. I know that I was not happy with that, but I forgot the reason. I 
think one was that the WrongAngleFixer started to move points too far. Anyway, 
I should fix this first.

I started to go for 32 bits because some algos which I coded for JOSM use this 
res. It seemed easier to change mkgmap to
also use 32 bits, but I am no longer sure about that.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 21. Februar 2017 18:44:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi

According to my calcs, full 32 bit integers give a resolution of about
10mm at the equator. Why do you need better than existing high-res (30
bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.

Not to have the resolution as a powerOfTwo of the garmin map unit would
require a lot of changes throughout the code and a run-time cost.

Manipulating high-res deltas such that the rounded values diverges from
the the std lat/long value seems very wrong (is this what it does, or
does it simply change one but not the other). Maybe wrong-angle stuff
should be looked at to see if there is a better way. This is an area
I've never been near.

Would be great if Area/bounds and Coord used the same (high-prec) units
and there was no ambiguity about contains().

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] RE Commit r3801: merge split-shape branch

[Ticker Berkin]

Hi

According to my calcs, full 32 bit integers give a resolution of about
10mm at the equator. Why do you need better than existing high-res (30
bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.
 
Not to have the resolution as a powerOfTwo of the garmin map unit would
require a lot of changes throughout the code and a run-time cost.

Manipulating high-res deltas such that the rounded values diverges from
the the std lat/long value seems very wrong (is this what it does, or
does it simply change one but not the other). Maybe wrong-angle stuff
should be looked at to see if there is a better way. This is an area
I've never been near.

Would be great if Area/bounds and Coord used the same (high-prec) units
and there was no ambiguity about contains().

Ticker


 

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

[Gerd Petermann]

Hi Andrzej,

sounds possible, but would require lots of difficult changes.
That's the problem, each possible way seems to include lots of changes :-(
I think the first step is to code more unit tests ...

Gerd




Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 21. Februar 2017 13:13:25
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Gerd,

could you really make a map, which include both +180 and -180
coordinates? I create a map of Asia and I intentionally limit area to
179., because of compilation problems.

Maybe if you limit input data that way, that you never process -180 and
+180 at the same time, then you could ignore double meaning of +-180?

--
Best regards,
Andrzej
___
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] RE Commit r3801: merge split-shape branch

[Andrzej Popowski]

Hi Gerd,

could you really make a map, which include both +180 and -180 
coordinates? I create a map of Asia and I intentionally limit area to 
179., because of compilation problems.


Maybe if you limit input data that way, that you never process -180 and 
+180 at the same time, then you could ignore double meaning of +-180?


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] aeroway in default style

[Andrzej Popowski]

Hi Gerd,

functions like proposed create_area() perform tasks, that I usually 
would do with a GIS program. Unfortunately processing OSM is not easy 
like for example SHP. That's why I'd like to put some of these functions 
into mkgmap. It's not a good solution but could be convenient.


create_area() could be usable for maps with or without TYP. I don't 
suggest to work on it, I only share some ideas.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

[Gerd Petermann]

Hi Andrzej,

no, it causes lots of problems.
For example, the bounding box for planet is (-90.0, -180.0, 90.0, 180.0).
If we don't distinct the positions of the left side from the right the area is 
a line with width 0.

The funny thing is that the precision in OSM doesn't even use all possible 32 
bit integers, only those for
-180 * 10_000_000 to 180 * 10_000_000  so the extreme values near 
Integer.MAX_VALUE are never used
(at least that is the conversion done in pbf or o5m format).

I think about using this format for Coord and maybe also Area.

Gerd

Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 21. Februar 2017 12:23:57
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Gerd,

 > I found new problems, e.g. 180.0 degrees and -180.0 degrees started
 > to give the same 32 bit value.

Isn't it good? The same is true for 24 bit precision and even for 8bit
angles.

--
Best regards,
Andrzej
___
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] RE Commit r3801: merge split-shape branch

[Andrzej Popowski]

Hi Gerd,

> I found new problems, e.g. 180.0 degrees and -180.0 degrees started
> to give the same 32 bit value.

Isn't it good? The same is true for 24 bit precision and even for 8bit 
angles.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

[Gerd Petermann]

Hi Ticker,

I thought about this for a while and I am still not sure where to go.

One problem with the high-prec stuff is that it is missleading.
When I started to code the highprec() code my only intention was to be able to
retreive "the original" position as coded in OSM.
You probably learned it the hard way that the value returned by 
Coord.getLatitude()
sometimes is different to the value from a rounded Coord.getHighPrecLat() .
The reason is that functions like Coord.getAlternativePositions() used by 
WrongAngleFixer
create Coord instances with the same highprec positions but different rounding 
(a bit more to
the left or right, a bit more up or down). The idea is that the map looks 
better when
the error for that single point is increased. A good place to check this are 
multiple parallel rails.

I am still trying to find good code to calculate the bounding box for coords 
with this special case.
When such a point is close to or "on" the bounding box in one precision it 
might be outside
with the other. I wonder if it would be better to use low precision as soon as 
possible.

If you have a good idea for that please let me know.

In the meantime I have found some reasons to change precision from 30 to 32 bit 
as this helps when
checking mp-relations. I found new problems, e.g. 180.0 degrees and -180.0 
degrees started to give the
same 32 bit value. Working on that now...

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 17. Februar 2017 15:49:10
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Gerd

Thoughts were:

I was having problems with a multi-polygon relation where OSM showed a
very small gap between 2 parts, but some final cutting of the shape
found that these lines now intersected, and I thought it could be a
mapPrec vs highPrec problem where the multiPolygonRelation logic is
looking for this sort of thing. Changing it to highPrec didn't fix it
(you found that the problem was roundCoord filter) but the changes
looked worth keeping because:

MultiPolygon cutting to expose holes uses highPrec and it seemed best
to be consistent, avoiding cuts that might leave very small areas.

A general move in the direction of all coordinates/bounds/etc being the
held only in highPrec and resolution 24 not being a special case.

But I don't have strong feelings about it.

Ticker

On Fri, 2017-02-17 at 13:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I did not see an advantage in using high-prec. Why do you think it
> should be used?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Freitag, 17. Februar 2017 13:27:28
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Yes - sorry, my fault.
> I've just tested a fix to this and the sea is OK now. Is is worth
> keeping the high-res changes in the split-shape branch pending more
> work on MultiPolygonRelation? If so I'll commit.
>
> Ticker
>
>
> On Fri, 2017-02-17 at 10:49 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > problem is in these lines:
> > if (remove) {
> > // check if the polygon contains
> > the
> > complete bounding box
> > if
> > (w.getBounds().contains(tileArea.getBounds())) {
> > remove = false;
> > }
> > }
> > 1) The SeaGenerator creates an outer way which is larger than the
> > tile bounds.
> > 2) This test was wrong because w.getBounds() returns a bbox  in
> > highprec values and tileArea.getBounds()  is in Garmin units
> >
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Freitag, 17. Februar 2017 11:00:49
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > Good.
> >
> > Ticker
> >
> > On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > attached is the patch I've created with help of svn.
> > > It only reverts the changes made to MultiPolygonRelation in
> > > r3771.
> > >
> > > I don't know yet why they cause trouble.
> > >
> > > Gerd
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Freitag, 17. Februar 2017 10:32:11
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Gerd
> > >
> > > Yes - if that 

Re: [mkgmap-dev] aeroway in default style

[Gerd Petermann]

Hi Andrzej,

sorry, I somehow missid this post before. I agree in all points.
The "create_area" function  seems a bit too special as it only makes sense for 
maps without a TYP file, right?

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Samstag, 18. Februar 2017 00:29
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] aeroway in default style

Hi Gerd,

I can't see any easy way to make runway visible over a road, without
using a TYP.

I treat default style as some kind of reference. An attempt to solve
this problem would result in cluttering of the style or use of
non-standard objects. Both approach would destroy educational values of
style and probably results would be rather mediocre. So I prefer to
ignore runway.

W can create additional POI for this kind of runway, but I think mappers
add a POI anyway, so this could be superfluous.

Just a thought: if we get a function like line-to-area, then w could
draw a runway below road as an area. I imagine rule like this:

aeroway=runway & highway=* & is_closed()!=true { create_area(20m); }

This should result in a new polygon created as a strip with 20m width,
which then would be processed according to rules in polygon file.

--
Best regards,
Andrzej
___
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