[mkgmap-dev] max-nodes in splitter

[Jakob Mühldorfer]

Hi,

I tried to read all the docs and forums about max-nodes, but I still 
have questions left:


 * Does the splitter print an error when max-nodes is too large, or is
   it unpredictable and will it only fail on the GPS device
 * Do tiles with more nodes mean higher or lower draw performance on
   devices, or not matter at all


Thank you for your help
Jakob

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

Re: [mkgmap-dev] patch to write polygons in decreasing order

[Gerd Petermann]

Hi Ticker,

Ticker Berkin wrote
> I think the reason why the buildings look different is because, without
> --order-by-decreasing-area, they get merged into a single area and then
> a filter (DouglasPeucker), finding the intermediate points are within
> the tolerance of a straight line, removes all but the 4 corners of the
> complete block. With --order-by, they are output individually as
> accurately as possible, but, because we are at/beyond at the limit of
> accuracy, rounding effects become obvious.

forgot to reply on this. You are right, only it's not DouglasPeucker but  
RemoveObsoletePointsFilter which removes the nodes at resolution 24. 
(DP filter is skipped also for shapes at res 24)

Gerd



--
View this message in context: 
http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5885764.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 r3702: sortAreas_v5.patch: Add option --order-by-decreasing-area

[svn commit]

Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016

sortAreas_v5.patch: Add option --order-by-decreasing-area

Patch by Ticker Berkin, slightly modifed


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

Re: [mkgmap-dev] patch to write polygons in decreasing order

[Ticker Berkin]

Hi Gerd

I think the reason why the buildings look different is because, without
--order-by-decreasing-area, they get merged into a single area and then
a filter (DouglasPeucker), finding the intermediate points are within
the tolerance of a straight line, removes all but the 4 corners of the
complete block. With --order-by, they are output individually as
accurately as possible, but, because we are at/beyond at the limit of
accuracy, rounding effects become obvious.

You mentioned GPSMapEdit not showing the smaller shape on top of the
larger. Using it to look at your test case of buildings in Bremen, and
the difference between with/without the option, I think it might apply
the size rule itself - drawing smaller shapes on top of larger. The
example I found was Penny supermarket @ 53.06650,8.79501 straddling a
number of buildings. With the buildings merged, it is smaller and hence
shows. With them separate, the buildings are smaller and they show.
Does this fit with your observations? Which examples were you looking
at? www.openstreetmap.org doesn't show Penny either.

I didn't use Util.roundUp because I wanted something to round to the
closest power of 2 and it rounds up to the next power of 2. I've
improved the javaDoc text for roundPof2.

I've made the other changes and attach a patch.

Regards
Ticker



On Fri, 2016-11-11 at 11:37 +, Ticker Berkin wrote:
> Hi Gerd
> 
> I'll check on the rounding, fix the warn>debug and add the pre-test
> to
> the splitting into areas.
> 
> I've just loaded GPSMapEdit and see what you mean about the long
> lines
> of buildings - they are wavy!. I'll work out why it is happening.
> 
> Regards
> Ticker 
>  
> On Fri, 2016-11-11 at 01:25 -0700, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > sorry, still some problems:
> > 1) I think I found an error in method Area.roundPof2(int val, int
> > shift)
> > I wanted to find out why you did not use Util.roundUp(int val, int
> > shift). 
> > 
> > For val=-9567 and shift=4 I see 
> > -9568 from your routine and
> > -9552 from the other
> > So it seems your routine doesn't round up as the javadoc says. 
> > So either the doc or the result is wrong.
> > 
> > 2) Please check the new log messages. The severity level warning
> > should not
> > be used for debug messages.
> > A warning message should be understandable for the end user.
> > 
> > 3) Reg. performance:
> > I think most of the area.intersect calls are not needed when you
> > add
> > this
> > block at the beginning of
> > splitIntoAreas():
> > // quick check if bbox of shape lies fully inside one
> > of the areas 
> > for (int areaIndex = 0; areaIndex < areas.length;
> > ++areaIndex) {
> > if
> > (areas[areaIndex].getBounds().contains(e.getBounds())) {
> > used[areaIndex] = true;
> > areas[areaIndex].addShape(e);
> > return;
> > }
> > }
> > // Shape crosses area(s), we have to split it
> > // Convert to a awt area
> >...
> > 
> > ciao,
> > Gerd
> > 
> > 
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://gis.19327.n8.nabble.com/patch-to
> > -write-polygons-in-decreasing-order-tp5884038p5885742.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-devIndex: doc/options.txt
===
--- doc/options.txt	(revision 3701)
+++ doc/options.txt	(working copy)
@@ -705,3 +705,8 @@
 
 ;--verbose
 : 	Makes some operations more verbose. Mostly used with --list-styles.
+
+;--order-by-decreasing-area
+:	Puts area/polygons into the mapfile in decreasing size so
+that smaller features are rendered over larger ones
+(assuming _drawOrder is equal).
Index: resources/help/en/options
===
--- resources/help/en/options	(revision 3701)
+++ resources/help/en/options	(working copy)
@@ -699,3 +699,8 @@
 
 --verbose
 	Makes some operations more verbose. Mostly used with --list-styles.
+
+--order-by-decreasing-area
+	Puts polygons/areas into the mapfile in decreasing size so that
+	smaller features are rendered over larger ones (assuming _drawOrder
+	is equal)
Index: src/uk/me/parabola/imgfmt/app/Area.java
===
--- src/uk/me/parabola/imgfmt/app/Area.java	(revision 3701)
+++ src/uk/me/parabola/imgfmt/app/Area.java	(working copy)
@@ -19,6 +19,7 @@
 import java.util.ArrayList;
 import java.util.List;
 
+import uk.me.parabola.imgfmt.MapFailedException;
 

Re: [mkgmap-dev] Spurious points & Basecamp blank tiles

[Gerd Petermann]

Hi Teemu,

Maybe I have a fix for this. We have special code in mkgmap for
POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities
and those are special.
With the attached patch only those with subtype = 0 are:
type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0

This seems to fix the problem, but maybe it is only a workaround.
Another observation: The MP file gives a label for each of these 0x1001 POI,
the pbf file doesn't.

A binary based on r3701 is here:
http://files.mkgmap.org.uk/download/312/mkgmap.jar

type_0x1001.patch
  

Gerd


Teemu Peltonen wrote
> Hi,
> 
> http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with 
> cGPSmapper and contains point type 0x1001 (among other rather exotic 
> types) without problems. Polish map file used to generate this file can 
> be found from http://kartat.hylly.org/mkgmap/M431.7z.
> 
> It also looks like that these artifacts does not exists when the img is 
> created from a pbf file containing no actual OSM data. Map generated 
> from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style 
> definitions works perfectly fine. 0x1001 points are, however missing so 
> they might definitely be part of the problem. The only difference 
> between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is 
> that OSM data is merged to M431_osm.osm.pbf with osmconvert.
> 
> -Teemu
> 
> 9.11.2016, 13:40, Gerd Petermann kirjoitti:
>> Hi Teemu,
>>
>> please provide a link to a small map with an 0x1001 type created with
>> cGPSmapper. Maybe we can learn from that.
>>
>> Gerd
>>
>>
>> Teemu Peltonen wrote
>>> Hi,
>>>
>>> those same types worked with cGPSmapper without a problem. Thank you for
>>> this insight, I'll try to change types and see what happens.
>>>
>>> -Teemu
>>>
>>> On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski 
>>> popej@.onet
>>> 
>>> wrote:
>>>
 Hi,

 I have once created a test map for all possible objects, using
 cGPSmapper.
 I have found, that some objects are problematic. I don't remember
 details,
 but I think sometimes map doesn't work at all.

 My current set of good points exclude 0x1001. Actually I think that for
 types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types
 doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.

 I don't know if this is a problem of Garmin devices or cGPSmapper.

 --
 Best regards,
 Andrzej






 ___
 mkgmap-dev mailing list

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

>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@.org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885635.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> ___
>> mkgmap-dev mailing list
>> 

> mkgmap-dev@.org

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

> mkgmap-dev@.org

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





--
View this message in context: 
http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885745.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

Re: [mkgmap-dev] patch to write polygons in decreasing order

[Gerd Petermann]

Hi Ticker,

sorry, still some problems:
1) I think I found an error in method Area.roundPof2(int val, int shift)
I wanted to find out why you did not use Util.roundUp(int val, int shift). 

For val=-9567 and shift=4 I see 
-9568 from your routine and
-9552 from the other
So it seems your routine doesn't round up as the javadoc says. 
So either the doc or the result is wrong.

2) Please check the new log messages. The severity level warning should not
be used for debug messages.
A warning message should be understandable for the end user.

3) Reg. performance:
I think most of the area.intersect calls are not needed when you add this
block at the beginning of
splitIntoAreas():
// quick check if bbox of shape lies fully inside one of the 
areas 
for (int areaIndex = 0; areaIndex < areas.length; ++areaIndex) {
if 
(areas[areaIndex].getBounds().contains(e.getBounds())) {
used[areaIndex] = true;
areas[areaIndex].addShape(e);
return;
}
}
// Shape crosses area(s), we have to split it
// Convert to a awt area
   ...

ciao,
Gerd





--
View this message in context: 
http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5885742.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