[mkgmap-dev] Gmapibuilder: Searching for new site to host source code

[Patrick Steiner]

Hi all,

is there already a new host for the source code?
Or could someone point me to the python file?

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

Re: [mkgmap-dev] splitter patch for enabling uncompressed tile outputs

[Chris Miller]

Hi Christoph,

I'll apply this patch in a week or so once I get back home. In the meantime 
though, I'd be interested to hear about the performance problems you're seeing 
with the splitter. Do you think it is due to the cpu time required for the 
compression, or something else? Why do you want to disable the gzipped output?

Regards,
Chris


> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enig89B73E3FE17316F7A6ECBF28
> Content-Type: multipart/mixed;
> boundary="000707010409030508090004"
> This is a multi-part message in MIME format.
> --000707010409030508090004
> Content-Type: text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding: quoted-printable
> Hello list,
> 
> I wanted to test some performance issues with splitter and so I needed
> to=
> switch of the gzip compression of the output tiles.
> Based on a patch that Thilo Hannemann wrote in may last year I made a
> new=
> patch for the latest splitter version now.
> Please can somebody submit this patch to the splitter svn? Maybe other
> pe= ople need this, too.
> 
> You can give a commandline switch like
> 
> splitter.jar --uncompressed
> 
> or
> 
> splitter.jar --uncompressed=3Dtrue
> 
> to switch of the compression for the output tiles. Default is to
> compress= =2E
> 
> Thanks!
> Christoph
> --000707010409030508090004
> Content-Type: text/x-patch;
> name="uncompressed.patch"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline;
> filename="uncompressed.patch"
> Index: src/uk/me/parabola/splitter/args/SplitterParams.java
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- src/uk/me/parabola/splitter/args/SplitterParams.java  (Revision
> 105)
> +++ src/uk/me/parabola/splitter/args/SplitterParams.java
> (Arbeitskopie)
> @@ -63,4 +63,7 @@
> =20
> @Option(description =3D "Don't trim empty space off the edges of
> tiles.=
> ")
> boolean isNoTrim();
> +
> + @Option(description =3D "Don't gzip output tiles if --uncompressed
> is g=
> iven.")
> + boolean isUncompressed();
> }
> Index: src/uk/me/parabola/splitter/Main.java
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- src/uk/me/parabola/splitter/Main.java (Revision 105)
> +++ src/uk/me/parabola/splitter/Main.java (Arbeitskopie)
> @@ -77,6 +77,8 @@
> // Set if there is a previous area file given on the command line.
> private AreaList areaList;
> private boolean mixed;
> + // The option "--uncompressed" will turn off compression of the
> output =
> data.
> + private boolean uncompressed;
> // The path to the disk cache. If this is null, no cache will be
> genera=
> ted or used.
> private String diskCachePath;
> // Whether or not a new cache needs to be generated.
> @@ -215,6 +217,7 @@
> geoNamesFile =3D params.getGeonamesFile();
> resolution =3D params.getResolution();
> trim =3D !params.isNoTrim();
> + uncompressed =3D params.isUncompressed();
> if (resolution < 1 || resolution > 24) {
> System.err.println("The --resolution parameter must be a value
> betwee=
> n 1 and 24. Resetting to 13.");
> resolution =3D 13;
> @@ -341,7 +344,7 @@
> for (int j =3D 0; j < currentWriters.length; j++) {
> Area area =3D areas.get(i * maxAreasPerPass + j);
> currentWriters[j] =3D new OSMWriter(area);
> - currentWriters[j].initForWrite(area.getMapId(), 
> overlapAmount);
> + currentWriters[j].initForWrite(area.getMapId(), 
> overlapAmount,
> uncom=
> pressed);
> }
> =20
> System.out.println("Starting pass " + (i + 1) + " of " +
> passesRequir=
> ed + ", processing " + currentWriters.length +
> @@ -431,7 +434,11 @@
> w.println("# description: OSM Map");
> else
> w.println("description: " + a.getName());
> - w.format("input-file: %d.osm.gz\n", a.getMapId());
> + if (uncompressed) {
> + w.format("input-file: %d.osm\n", a.getMapId());
> + } else {
> + w.format("input-file: %d.osm.gz\n", 
> a.getMapId());
> + }
> }
> =20
> w.println();
> Index: src/uk/me/parabola/splitter/OSMWriter.java
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- src/uk/me/parabola/splitter/OSMWriter.java(Revision 105)
> +++ src/uk/me/parabola/splitter/OSMWriter.java(Arbeitskopie)
> @@ -34,16 +34,26 @@
> this.bounds =3D bounds;
> }
> =20
> - public void initForWrite(int mapId, int extra) {
> + public vo

Re: [mkgmap-dev] typfile: Drawing order

[Marko Mäkelä]

22.03.2010 00.18.20, Daniela Duerbeck wrote:
> Which drawing order are you using for woods and lakes? I found a  
> situation:
> http://www.openstreetmap.org/?
> lat=47.9066&lon=11.5221&zoom=14&layers=B000FTF
> 
> where a lake is inside a wood and with drawing order 5 for both I  
> just see the wood.

That is not a drawing order thing. There should be a multipolygon with  
the woods in role=outer and the lake in role=inner. And that appears to  
be the case since last night:

http://www.openstreetmap.org/browse/way/10901211

It should be OK in tomorrow's Geofabrik dump, I guess.

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

Re: [mkgmap-dev] typfile: Drawing order

[charlie]

Daniela Duerbeck (daniela.duerb...@gmx.de) wrote:

> Hi!
>
> Which drawing order are you using for woods and lakes? I found a
> situation:
> http://www.openstreetmap.org/?lat=47.9066&lon=11.5221&zoom=14&layers=B000FTF
> where a lake is inside a wood and with drawing order 5 for both I just
> see the wood.
>
> TIA,
> Dani

I had a similar problem with a golf course inside a park.  As in my  
TYP file they both had the same draw order, I could only see the park.  
  Obviously I can set golf-courses to have a higher draw order, but  
then in future if I ever get a park inside a golf course it won't  
display.  I'm not sure there's a way around this problem (unless you  
can have double-definition polygons at different draw orders to  
account for this, but I doubt that would work).


-- 
Charlie

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

[mkgmap-dev] Commit: r1608: Berteun Damman's gmapi-builder script that converts from the MapSource

[svn commit]

Version 1608 was commited by steve on 2010-03-22 09:55:42 + (Mon, 22 Mar 
2010) 

Berteun Damman's gmapi-builder script that converts from the MapSource
format to directory structure that is used by RoadTrip on OS X.
The original script was also modified by Clinton Gladstone.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gmapibuilder: Searching for new site to host source code

[Steve Ratcliffe]

Hi

> is there already a new host for the source code?
> Or could someone point me to the python file?

Sorry I received the file ages ago, but didn't add it at the time.  I
have now done this and it can be accessed at:

   http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py

Regards,

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

Re: [mkgmap-dev] Gmapibuilder: Searching for new site to host source code

[Patrick Steiner]

Thanks,

I will post this link also in the osm wiki.

regards,
  patrick

On 22.03.2010 11:00, Steve Ratcliffe wrote:
>
> Hi
>
>> is there already a new host for the source code?
>> Or could someone point me to the python file?
>
> Sorry I received the file ages ago, but didn't add it at the time.  I
> have now done this and it can be accessed at:
>
>   http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py
>
> Regards,
>
> ..Steve

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

[mkgmap-dev] debugging ferries

[Chris-Hein Lunkhusen]

Hi,
I tested the ferry routing with mkgmap default style and found
that my Nüvi was not able to route me to Borkum.

When I set a via point on the ferry route it works ok,
but without this via point mapsource does "direct line
routing".

MS screenshot:



There is no tile-boundary in between.

Chris

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

Re: [mkgmap-dev] debugging ferries

[Mark Burton]

Hello Chris,

I found that I had to set the ferry road class to 3 to be able to
reliably route using them.

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

Re: [mkgmap-dev] debugging ferries

[Chris-Hein Lunkhusen]

Mark Burton schrieb:

> I found that I had to set the ferry road class to 3 to be able to
> reliably route using them.

Ohhh. So maybe this should be changed in the default style.

Chris

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

[mkgmap-dev] Commit: r1609: Use road_class 3 for route=ferry.

[svn commit]

Version 1609 was commited by marko on 2010-03-22 10:43:13 + (Mon, 22 Mar 
2010) 

Use road_class 3 for route=ferry.
Mark Burton says that this is needed for reliable routing.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] debugging ferries

[Marko Mäkelä]

22.03.2010 12.33.10, Chris-Hein Lunkhusen wrote:
> Mark Burton schrieb:
> 
> > I found that I had to set the ferry road class to 3 to be able to
> > reliably route using them.
> 
> Ohhh. So maybe this should be changed in the default style.

Consider it done in revision 1609.

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

[mkgmap-dev] process same input data with mkgmap with different styles at the same time

[Christoph Wagner]

Hello list,

I try to make Garmin maps with different layers.
http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map

The idea is, that you can enable or disable some transparent maps that you 
won't see.
For this reason I use mkgmap with different options and stylefiles multiple 
times on the same input data:

java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data
java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data
java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data
...


This works good, but is not with so good performance as it could be.
The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has 
to decompress and parse the same stuff.

The cleverst solution I could imagine is to start mkgmap once and give it 
different options at the same time for different threads for example:
java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 
[options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 
--outputdir=dir3 input_data

The question is: How difficult is it to implement in mkgmap? I looked at the 
source code but didn't understand enough to implement it. In germany we would 
say I looked at the code like a pig at a clockwork. ;)
I think a problem is that at the moment the order of commandline args doesn't 
matter but then it would be important which option belongs to which thread.

Maybe another solution could be to build a cache - like the tilesplittercache, 
where mkgmap can store the parsed input_data.
Another mkgmap instance could use this cache instead of the input data. Maybe 
this solution would be more easy to implement or am I wrong?
So something like:
java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir 
input_data
java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir
java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir

What do you think about that ideas?
Btw: Can I specify an output directory for mkgmap or is it everytime the actual 
directory?

Thanks!
Christoph



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

Re: [mkgmap-dev] Commit: r1609: Use road_class 3 for route=ferry.

[Mark Burton]

> Use road_class 3 for route=ferry.
> Mark Burton says that this is needed for reliable routing.

That was rather quick. Let's hope I'm right.

As for evidence, here's an example route that has uses two ferries and
has no intermediate way points.

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

Re: [mkgmap-dev] process same input data with mkgmap with different styles at the same time

[Mark Burton]

Hello Christoph,

> Hello list,
> 
> I try to make Garmin maps with different layers.
> http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map
> 
> The idea is, that you can enable or disable some transparent maps that you 
> won't see.
> For this reason I use mkgmap with different options and stylefiles multiple 
> times on the same input data:
> 
> java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data
> java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data
> java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data
> ...
> 
> 
> This works good, but is not with so good performance as it could be.
> The input data are gzipped osm-tiles of europe and everytime mkgmap runs it 
> has to decompress and parse the same stuff.
> 
> The cleverst solution I could imagine is to start mkgmap once and give it 
> different options at the same time for different threads for example:
> java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 
> [options2] --style-file=style2 --outputdir=dir2 [options3] 
> --style-file=style3 --outputdir=dir3 input_data
> 
> The question is: How difficult is it to implement in mkgmap? I looked at the 
> source code but didn't understand enough to implement it. In germany we would 
> say I looked at the code like a pig at a clockwork. ;)

That's a great phrase!

But to answer your question. I think it would be a lot of work to do
what you are suggesting and really not the best solution. If I was
trying to do what you are doing I would simply de-compress the input
once (disk space is cheap) and then run separate mkgmap sessions as
before. You could also pre-process the XML to filter out all of the
crap tags that you are not interested in. That would speed up the
processing by mkgmap.

> I think a problem is that at the moment the order of commandline args doesn't 
> matter but then it would be important which option belongs to which thread.
> 
> Maybe another solution could be to build a cache - like the 
> tilesplittercache, where mkgmap can store the parsed input_data.
> Another mkgmap instance could use this cache instead of the input data. Maybe 
> this solution would be more easy to implement or am I wrong?
> So something like:
> java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir 
> input_data
> java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir
> java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir
> 
> What do you think about that ideas?
> Btw: Can I specify an output directory for mkgmap or is it everytime the 
> actual directory?
> 
> Thanks!
> Christoph
> 

Cheers,

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

Re: [mkgmap-dev] typfile: Drawing order

[Daniela Duerbeck]

> be the case since last night:
>
> http://www.openstreetmap.org/browse/way/10901211
>   
Aaaah. Tante grazie, Matteo ... :-)))

I think, he has read my question here and corrected it.

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

Re: [mkgmap-dev] [PATCH v6] - Code around highway shield crap when sorting labels

[Felix Hartmann]

On 22.03.2010 00:42, Mark Burton wrote:

v6 - don't trash first ref if it is the same as the name (sans shield)
and more refs follow

-
In principle the patch works very good. I do get complications when 
using this patch in combination to Wan Mill's "mp_lesscuts_v4.patch".


It would be great if the following patches could be added to trunk, for 
me they all work very well:

empty_labels.patch
mp_lesscuts_v4.patch (causes some problems in combination with above 
patch v6)

mp_rolehandling_v3.patch
sizeFilter.patch (previously called drop_small_polygons.patch)

I'm attaching them all here, in order for no need to search the ML

Here is the error I'm getting with patch v6 and mp_lesscuts
D:\Garmin\mkgmap_680\maps>start /low /b /wait java -ea -jar -Xmx1250M 
d:\garmin\mkgmap_680\mkgmap.jar --style-file=d:\garmin\mkgmap_680\new4 
--max-jobs=3 --generate-sea=polygons,extend-sea-sectors,close-gaps=6000 
--reduce-point-density=5.4 --reduce-point-density-polygon=8
 --suppress-dead-end-nodes --index 
--delete-tags-file=d:\garmin\mkgmap_680\new4\deletetags --transparent 
--blacklist-tags-file=deletetags --adjust-turn-headings 
--ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 
--description=openmtbmap_at --location-auto
fill=2 --route --country-abbr=at --country-name=austria 
--mapname=6322 --family-id=6322 --product-id=1 
--series-name=openmtbmap_at_22.03.2010 
--family-name=mtbmap_at_22.03.2010 --tdbfile --overview-mapname=mapset 
--area-name="austria_22.03.2010_openmtbmap.org" -c d:\g

armin\mkgmap_680\maps\template.args
java.lang.NullPointerException
at 
uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327)
at 
uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538)
at 
uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation(Osm5XmlHandler.java:594)
at 
uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(Osm5XmlHandler.java:564)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at 
com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endElement(XIncludeHandler.java:1014)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at 
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)

at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
at 
uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:81)
at 
uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148)

at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186)
at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:619)
Exiting - if you want to carry on regardless, use the --keep-going option

D:\Garmin\mkgmap_680\maps>echo end 15:13:00 1>>time.log



Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java  
(revision 1599)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java  
(working copy)
@@ -7,15 +7,19 @@
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.BitSet;
+import java.util.Collection;
 import java.util.Collections;
+import java.util.Comparator;
 import java.util.HashMap;
 

Re: [mkgmap-dev] [PATCH v6] - Code around highway shield crap when sorting labels

[Mark Burton]

Hi Felix,

> On 22.03.2010 00:42, Mark Burton wrote:
> > v6 - don't trash first ref if it is the same as the name (sans shield)
> > and more refs follow
> >
> > -
> In principle the patch works very good.

Good.

> I do get complications when using this patch in combination to Wan Mill's 
> "mp_lesscuts_v4.patch".

Isn't that patch already in the trunk?
 
> It would be great if the following patches could be added to trunk, for 
> me they all work very well:
> empty_labels.patch

This is also in trunk now.

> mp_lesscuts_v4.patch (causes some problems in combination with above 
> patch v6)

> mp_rolehandling_v3.patch
> sizeFilter.patch (previously called drop_small_polygons.patch)

Don't know the status of those patches.


> java.lang.NullPointerException
>  at 
> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327)
>  at 
> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538)

Actually, if you look at the code, that NPE should be impossible to
achieve. Something very odd is happening - can you try again using a
clean build (ant clean; ant)

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

[mkgmap-dev] Using multiple TYP files

[Toby Speight]

I'm having trouble combining IMG files with different product and family
IDs into a single gmapsupp.img.  I can create single-family images with
no problem, but trying to create a multiple-family image thusly:

/
| $(MKGMAP) --gmapsupp \
|--family-id=1672 --product-id=1672 1672*.img 1672.TYP \
|--family-id=6324 --product-id=6324 6324*.img 6324.TYP
\

results in all the image files getting the 6324 IDs, and so the 1672*
files appear in the wrong style.  It also means that I can't selectively
show or hide the two families.

How best to combine the two?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Using multiple TYP files

[Christoph Wagner]

2010/3/22 Toby Speight :

> /
> | $(MKGMAP) --gmapsupp \
> |    --family-id=1672 --product-id=1672 1672*.img 1672.TYP \
> |    --family-id=6324 --product-id=6324 6324*.img 6324.TYP
> \

> How best to combine the two?

Do it sequentially.

$(MKGMAP) --gmapsupp  --family-id=1672 --product-id=1672 1672*.img 1672.TYP
mv gmapsupp.img gmapsupp1.img
$(MKGMAP) --gmapsupp  --family-id=6324 --product-id=6324 6324*.img 6324.TYP
mv gmapsupp.img gmapsupp2.img
$(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img

Then you get a gmapsupp.img that contains what you want.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Using multiple TYP files

[Steve Ratcliffe]

Hi

> /
> | $(MKGMAP) --gmapsupp \
> |--family-id=1672 --product-id=1672 1672*.img 1672.TYP \
> |--family-id=6324 --product-id=6324 6324*.img 6324.TYP
> \

That is supposed to work just as you have it.

I thought there was even a test for it!
I'll investigate.

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

Re: [mkgmap-dev] Using multiple TYP files

[Toby Speight]

0> In article <61af4ce51003220852q2e3efcccta68324526a77...@mail.gmail.com>,
0> Christoph Wagner mailto:freemaps@googlemail.com> ("CW") wrote:

CW> Do it sequentially.
CW>
CW> $(MKGMAP) --gmapsupp  --family-id=1672 --product-id=1672 1672*.img 1672.TYP
CW> mv gmapsupp.img gmapsupp1.img
CW> $(MKGMAP) --gmapsupp  --family-id=6324 --product-id=6324 6324*.img 6324.TYP
CW> mv gmapsupp.img gmapsupp2.img
CW> $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img
CW>
CW> Then you get a gmapsupp.img that contains what you want.

Ah, I didn't realise you could use a gmapsupp.img as input.  Your recipe
above works like a dream - many thanks!  :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Using multiple TYP files

[Toby Speight]

0> In article <87mxy0e691@balti.ashgrove>,
0> Toby Speight mailto:t.m.speight...@cantab.net> ("Toby") wrote:

Toby> /
Toby> | $(MKGMAP) --gmapsupp \
Toby> |--family-id=1672 --product-id=1672 1672*.img 1672.TYP \
Toby> |--family-id=6324 --product-id=6324 6324*.img 6324.TYP
Toby> \

Steve> That is supposed to work just as you have it.
Steve>
Steve> I thought there was even a test for it!
Steve> I'll investigate.

It's a while since I looked at the option parsing code, but IIRC, all
the non-file arguments are processed before starting to read any of the
files, contrary to the documentation.  I could be wrong, though.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v6] - Code around highway shield crap when sorting labels

[Felix Hartmann]

On 22.03.2010 15:29, Mark Burton wrote:
> Hi Felix,
>
>
>> On 22.03.2010 00:42, Mark Burton wrote:
>>  
>>> v6 - don't trash first ref if it is the same as the name (sans shield)
>>> and more refs follow
>>>
>>> -
>>>
>> In principle the patch works very good.
>>  
> Good.
>
>
>> I do get complications when using this patch in combination to Wan Mill's 
>> "mp_lesscuts_v4.patch".
>>  
> Isn't that patch already in the trunk?
>
I don't think so, based on nearly no complications on trying to add it.
>
>
>> It would be great if the following patches could be added to trunk, for
>> me they all work very well:
>> empty_labels.patch
>>  
> This is also in trunk now.
>
And how comes that I can still apply it - without it being there yet?
>
>> mp_lesscuts_v4.patch (causes some problems in combination with above
>> patch v6)
>>  
>
>> mp_rolehandling_v3.patch
>> sizeFilter.patch (previously called drop_small_polygons.patch)
>>  
> Don't know the status of those patches.
>
>
>
>> java.lang.NullPointerException
>>   at
>> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327)
>>   at
>> uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538)
>>  
> Actually, if you look at the code, that NPE should be impossible to
> achieve. Something very odd is happening - can you try again using a
> clean build (ant clean; ant)
>
>
I do that before every compile. As soon as I add mp_lesscuts_v4 it happens.
> Mark
> ___
> 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] Using multiple TYP files

[Ralf Kleineisel]

On 03/22/2010 05:36 PM, Toby Speight wrote:

> It's a while since I looked at the option parsing code, but IIRC, all
> the non-file arguments are processed before starting to read any of the
> files, contrary to the documentation.  I could be wrong, though.

Creating a gmapsupp.img with several family-IDs does work for me when I
use an options file with the "-c" option. Didn't try on the command
line, though.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels

[Clinton Gladstone]

On Mar 21, 2010, at 23:36, Mark Burton wrote:

> So, those people who are tracking this patch series, please test and if
> it doesn't bite your arse, I will commit it soonish

I tested v5 today. It seems to be OK. I'll try again with v6 tomorrow.

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

Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels

[Mark Burton]

Hi Clinton,

> I tested v5 today. It seems to be OK. I'll try again with v6 tomorrow.

Thanks.

Actually, I think that v6 is OK (as far as fixing Felix's routing
directions issue is concerned) and would like to commit it.

However, I am holding off committing the patches until Felix says some
more about the incompatibility issue with an MP patch. Any news Felix?

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

Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels

[Felix Hartmann]

On 22.03.2010 21:55, Mark Burton wrote:
> Hi Clinton,
>
>
>> I tested v5 today. It seems to be OK. I'll try again with v6 tomorrow.
>>  
> Thanks.
>
> Actually, I think that v6 is OK (as far as fixing Felix's routing
> directions issue is concerned) and would like to commit it.
>
> However, I am holding off committing the patches until Felix says some
> more about the incompatibility issue with an MP patch. Any news Felix?
>
> Mark
>
Well as the mp_lesscuts_v4 patch is already commited, the breakage must 
be expected as I tried to add a patch that is already included (well 
probably slightly different though).

Could you nevertheless also commit the sizeFilter.patch?
It comes very handy and I know that besides me, also Thilo 
(User:Radfahrer) is using it. A value of 8 is quite good for default 
right now. (Polygons smaller than 8 pixels except for resolution 24 are 
not worthwhile anyhow and only slow down the map redraw). It is pretty 
straightforward and I don't think it could break anything.

Also the mp_rolehandling_v3.patch should be committed too IMHO, because 
it really improves the maps.

P.S.: This is an updated patch to r1602.
> ___
> 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] [PATCH v5] - Code around highway shield crap when sorting labels

[Mark Burton]

Felix,

Thanks for the update.

> Well as the mp_lesscuts_v4 patch is already commited, the breakage must 
> be expected as I tried to add a patch that is already included (well 
> probably slightly different though).

OK.
 
> Could you nevertheless also commit the sizeFilter.patch?
> It comes very handy and I know that besides me, also Thilo 
> (User:Radfahrer) is using it. A value of 8 is quite good for default 
> right now. (Polygons smaller than 8 pixels except for resolution 24 are 
> not worthwhile anyhow and only slow down the map redraw). It is pretty 
> straightforward and I don't think it could break anything.

I will look at that - at this time I don't have any objection to it and
if no one raises any objections I will commit it in a day or so.

> Also the mp_rolehandling_v3.patch should be committed too IMHO, because 
> it really improves the maps.

Steve's been handling the MP patches, hopefully he will look at
incorporating that patch.

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

[mkgmap-dev] Commit: r1610: Added highway shield codes to Format6Encoder.LETTERS.

[svn commit]

Version 1610 was commited by markb on 2010-03-22 21:21:12 + (Mon, 22 Mar 
2010) 

Added highway shield codes to Format6Encoder.LETTERS.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1611: Added missing space to diagnostic message.

[svn commit]

Version 1611 was commited by markb on 2010-03-22 21:21:15 + (Mon, 22 Mar 
2010) 

Added missing space to diagnostic message.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1612: Don't let highway shield codes affect the order of the sorted roads.

[svn commit]

Version 1612 was commited by markb on 2010-03-22 21:21:19 + (Mon, 22 Mar 
2010) 

Don't let highway shield codes affect the order of the sorted roads.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1613: Don't duplicate road labels when ref is same as name when shield codes ignored.

[svn commit]

Version 1613 was commited by markb on 2010-03-22 21:21:22 + (Mon, 22 Mar 
2010) 

Don't duplicate road labels when ref is same as name when shield codes ignored.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1614: Make isUpperCase() public.

[svn commit]

Version 1614 was commited by markb on 2010-03-22 21:21:26 + (Mon, 22 Mar 
2010) 

Make isUpperCase() public.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1615: If required, case fold labels in newLabel() to avoid dups in label cache.

[svn commit]

Version 1615 was commited by markb on 2010-03-22 21:21:29 + (Mon, 22 Mar 
2010) 

If required, case fold labels in newLabel() to avoid dups in label cache.

Duplicate labels that only differed in letter case were being produced
because the label cache saw the label strings before they were case folded.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1616: Remove leading spaces from name element names.

[svn commit]

Version 1616 was commited by markb on 2010-03-22 21:21:35 + (Mon, 22 Mar 
2010) 

Remove leading spaces from name element names.

Taking care to preserve any initial Garmin code.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1617: Mask out the extra-bit flag from the line's type in linesForSubdiv().

[svn commit]

Version 1617 was commited by markb on 2010-03-22 21:21:39 + (Mon, 22 Mar 
2010) 

Mask out the extra-bit flag from the line's type in linesForSubdiv().
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1618: Strip all funky Garmin codes from the name string (not just the first char).

[svn commit]

Version 1618 was commited by markb on 2010-03-22 21:21:42 + (Mon, 22 Mar 
2010) 

Strip all funky Garmin codes from the name string (not just the first char).
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1619: Handle the 0x1b prefix for lower case letters (also used for two separators).

[svn commit]

Version 1619 was commited by markb on 2010-03-22 21:21:45 + (Mon, 22 Mar 
2010) 

Handle the 0x1b prefix for lower case letters (also used for two separators).
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1620: Can now explicitly tag boundary nodes with mkgmap:on-boundary=1.

[svn commit]

Version 1620 was commited by markb on 2010-03-22 21:24:01 + (Mon, 22 Mar 
2010) 

Can now explicitly tag boundary nodes with mkgmap:on-boundary=1.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Using multiple TYP files

[Steve Ratcliffe]

> CW>  $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img
> CW>
> CW>  Then you get a gmapsupp.img that contains what you want.
>
> Ah, I didn't realise you could use a gmapsupp.img as input.  Your recipe
> above works like a dream - many thanks!  :-)

You can although it was only fairly recently that it was implemented.

I'm not sure why your original command is not working, I've just tried
it and it works for me.  I'd need more information to look into it further.

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

Re: [mkgmap-dev] rolehandling patch

[Steve Ratcliffe]

> Steve's been handling the MP patches, hopefully he will look at
> incorporating that patch.

All of that patch (as far as I can see) was included in the r1607 patch.

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

Re: [mkgmap-dev] rolehandling patch

[Mark Burton]

Hi Steve,

> > Steve's been handling the MP patches, hopefully he will look at
> > incorporating that patch.
> 
> All of that patch (as far as I can see) was included in the r1607 patch.

Oh yes, it's already been done.

I've been so immersed in my own little world that I missed that one.

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