Re: [mkgmap-dev] Tile splitter and merged maps?
Hi Marko, Charlie, >> So looks like the tile splitter took into account only the first part of the >> merged .osm map. >> Am I doing something wrong here? Or is this an incompatibility or a possible >> problem with the tile splitter? > Would you use to use the --mixed option to splitter or does osmosis > automatically sort files when it merges them? Not sure whether osmosis sorts automatically. Now, I did a sort run before: $ ./osmosis --rx DE_FI_USW.osm --sort --wb DE_FI_USW.osm.pbf omitmetadata=true then tried splitting again. >From Marko's mail: > Side note: why not --wb DE_FI_USW.osm.pbf? Splitter can process osm.pbf. Thanks, I didn't know that. I had read posts about older versions of splitter that couldn't deal with pbf. > What kind of coordinates do you see in the areas.list? Could it be that > splitter is misinterpreting the bounding box? Areas only cover Finland :-( http://maps.google.com/maps?q=roettsches.de%2Fdominik%2Fareas.kml In the splitter output [1], the following bounding box is printed: "Bounding box 19.02427 59.28782 31.6008803 70.09959" how to interpret these values to check whether the map bounding box is right? If I use 19.02427 59.28782 in Google Maps, it shows a place in the Arabian Sea, the other coordinate is somewhere in Pakistan... Can I tell the splitter to ignore the map's bounding box altogether and find its own? Any other ideas how to make it take into account the whole merged map? Dominik [1] Splitter output: $ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=100 --write-kml=areas.kml ../DE_FI_USW.osm .pbf cache= description= geonames-file= legacy-mode=false mapid=63240345 max-areas=255 max-nodes=100 max-threads=8 (auto) mixed=false no-trim=false output-dir= overlap=2000 resolution=13 split-file= status-freq=120 write-kml=areas.kml Elapsed time: 0s Memory: Current 119MB (2MB used, 117MB free) Max MB Time started: Wed Apr 27 08:58:57 CEST 2011 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing ../DE_FI_USW.osm.pbf Bounding box 19.02427 59.28782 31.6008803 70.09959 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
> Areas only cover Finland :-( > http://maps.google.com/maps?q=roettsches.de%2Fdominik%2Fareas.kml Sorry, that link didn't work, here's the right one: http://maps.google.com/maps?q=http%3A%2F%2Froettsches.de%2Fdominik%2Fareas.kml d ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
On Wed, Apr 27, 2011 at 10:14:14AM +0300, Dominik Röttsches wrote: >Can I tell the splitter to ignore the map's bounding box altogether and >find its own? Any other ideas how to make it take into account the >whole merged map? Can you split each extract separately and then tell mkgmap to produce a map from the tiles generated by the three splitter runs? IIRC, I tried producing a combined map of finland.osm.bz2 and estonia.osm.bz2 in 2009, when I visited Tallinn. It sort of worked, but routing did not work in Tallinn. I did not investigate or experiment further. It could also have been due to bad map data; I only keep Finland tidy. :-) In 2010, I loaded just the Estonian map and then just a small area where I moved, for adding some pedestrian crossings and sidewalks and the like. You could use my hand-made areas.list for Finland. It tries hard to get a nice generate-sea. It also avoids splitting the Lake Päijänne multipolygon. One of your tile borders slices the lake. The tile border should be a little more west near the line Jämsä-Kuhmoinen-Padasjoki. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
On 27.04.2011, at 10:14, Dominik Röttsches wrote: > In the splitter output [1], the following bounding box is printed: > "Bounding box 19.02427 59.28782 31.6008803 70.09959" > how to interpret these values to check whether the map bounding box is right? This bounding box is only Finland: > 19.02427 59.28782 31.6008803 70.09959 The order is: Lower Left E, N - Top Right E, N i.e. N59.288 E19.024 to N70.1 E 31.601 So does osmosis not generate the correct bounding box? Dominik ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1926: When sorting, characters that have a sort position of zero
Version 1926 was commited by steve on 2011-04-27 09:21:37 +0100 (Wed, 27 Apr 2011) When sorting, characters that have a sort position of zero t a given strength are treated as if they were not present. This mainly affects how shields are treated in sorting. They are now ignored, except that the shields sort among themselves. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file: set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
Hi Marko, > Can you split each extract separately and then tell mkgmap to produce a > map from the tiles generated by the three splitter runs? Good idea, thanks. Generation seems to have worked, at least combining Finland and Germany. When adding US, it complained "map area too small to split". Will have to check that, maybe trying another split run on the US map with different parameters. Now downloading the result from my server and will test it on the gps device then later. > You could use my hand-made areas.list for Finland. It tries hard to get > a nice generate-sea. It also avoids splitting the Lake Päijänne > multipolygon. One of your tile borders slices the lake. The tile border > should be a little more west near the line Jämsä-Kuhmoinen-Padasjoki. That would be useful. Do you have it online somewhere? Or could you send it in a personal email? Thanks, Dominik ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
This is a copy of my windows Bat file. Hope it helps. bin\osmosis.bat -v --rx -b5 enableDateParsing=no file=planet.new.osm.gz --bb top=-6 left=107.1 bottom=-48 right=163.5 completeWays=yes completeRelations=yes --wx -bc5 file=o:\garmin\splitter\Australia.osm Regards, Markus_g -Original Message- From: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Minko Sent: Wednesday, 27 April 2011 7:31 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] [locator] Separate boundary files How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file: set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name ___ 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] [locator] Separate boundary files
You need to - infront of tf. --tf instead of -tf ;) Henning Am 27.04.2011 12:01, schrieb Minko: > How do I run osmosis in a windows batch file? If I put this line in the > osmosis.bat file: > > set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways > boundary=administrative -tf accept-relations boundary=administrative > --used-node -wx europe-boundaries.osm > > I get this error: only one default (un-named) argument can exist per task. > Arguments 3 and 2 have no name > ___ > 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] [locator] Separate boundary files
Thanks Henning, Probably in front of wx as well, otherwise I got an error again. Now it's running. set OSMOSIS_OPTIONS=--rb europe.osm.pbf --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
Thanks WanMil, just two questions are left: What about location-autofil and index? Are they needed both or just index? Is it possible to input boundary-file as pbf? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
On Wed, Apr 27, 2011 at 01:14:33PM +0300, Dominik Röttsches wrote: >> You could use my hand-made areas.list for Finland. >That would be useful. Do you have it online somewhere? Or could you >send it in a personal email? Ah, sorry, I forgot to add the link: http://www.polkupyoraily.net/osm/ http://www.polkupyoraily.net/osm/files/areas.list You can see the descriptions in osm2img.sh. I used to have a separate mkgmap.args file, but I wanted the flexibility of a shell script (in preparation for the multi-output-layer feature that I am going to prototype soonish). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
I came across a similar problem last year. The trouble was with the merge function of osmosis. It takes the bounding box of the output file, from the first input file, regardless of the bounding boxes of the other input files. But the data from all the input files is in the merged file. I contacted the maintainer of osmosis about this but received no reply. It may be that it is the intended behaviour, rather than a bug. I worked around this problem, but it is not at all convenient. You create the output file in uncompressed .osm format. This can result in a large file. Then you edit the file with a hexadecimal editor, because it will be too large to edit with a text editor. The bounds are very near to the start of the file. Use the hexadecimal editor to overwrite the bounds with the correct values. This way, you only need to rewrite one cluster, not the whole file. (For Mac, Hex Fiend from ridiculousfish.com is a good hex editor, free and open-source.) I have a vague recollection that it is also possible to get the splitter to ignore the bounds in the input file. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
On Wed, Apr 27, 2011 at 02:48:03PM +0100, Adrian wrote: >I worked around this problem, but it is not at all convenient. You >create the output file in uncompressed .osm format. This can result in >a large file. Then you edit the file with a hexadecimal editor, because >it will be too large to edit with a text editor. Another option would be to pipe it through a stream editor, such as sed, awk or perl. I did that at one point in my osm2img.sh, for two tasks: moving the coastline endpoints outside the tile borders, and removing broken multipolygons generated by a bot. The broken multipolygons have since then been fixed, and when switching to osm.pbf, I worked around the coastline endpoint problem by choosing my tile borders carefully. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
> Thanks WanMil, > just two questions are left: > > What about location-autofil and index? Are they needed both or just index? index is required. location-autofill should be set to 0. > Is it possible to input boundary-file as pbf? Not yet, but that's easy to implement so I will add it soon. WanMil > > Henning > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
Just run a small test, if I dont specify boundsdirectory, mkgmap complains about no boundary directory found. I got a few 'file not found messages' but I think they were caused by the fact that I ran osmosis with a bounding box that was too small (didnt want to process whole europe). The first results look very good. Seems that with this method a lot of issues are solved, like places are now in the correct Province and Country, and streets that once had no assigned place name can now be located. Thanks Wanmil, you have done an excellent job! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
> Just run a small test, if I dont specify boundsdirectory, mkgmap complains > about no boundary directory found. > I got a few 'file not found messages' but I think they were caused by the > fact that I ran osmosis with a bounding box that was too small (didnt want to > process whole europe). The first results look very good. Seems that with this > method a lot of issues are solved, like places are now in the correct > Province and Country, and streets that once had no assigned place name can > now be located. Thanks Wanmil, you have done an excellent job! Your results sounds fine! What do you say about performance? I was a bit disappointed about memory consumption and processing time. This has to be investigated and improved. I will have a look on your boundsdirectory error message. I would not expect it if you put the files in a subdirectory named bounds. But I didn't test it and the code is still in a prototype stage. So lot's of things to do :-) WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times. The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error on MapSource with r1919
I have the same problem with Mapsource here. Since r1919 Mapsource crashes again with OSM Europe, when you try to select tiles to be uploaded to the GPS. You can view the tiles, zoom in and out. All fine, but as soon as you select one tile Mapsosurce crashes. Yet the error is different than the last time. It's not DSK_PRIVPARTITION.CPP-312-6.16.3.0 anymore but the following: Problemsignatur: Problemereignisname: BEX Anwendungsname: MapSource.exe Anwendungsversion: 6.16.3.0 Anwendungszeitstempel: 4cb7231f Fehlermodulname: MapSource.exe Fehlermodulversion: 6.16.3.0 Fehlermodulzeitstempel: 4cb7231f Ausnahmeoffset: 00850a8b Ausnahmecode:c417 Ausnahmedaten: Betriebsystemversion:6.1.7601.2.1.0.256.1 Gebietsschema-ID:1031 Zusatzinformation 1: 9738 Zusatzinformation 2: 9738xxxd30ecxxxc669fe3exxxf68aad Zusatzinformation 3: a536 Zusatzinformation 4: a536xxxa446cxxxf34b149dxxx3c718f The last change to the ImgHeader.java seemed to cause the problem. No single tile is >50 MB, osmmap_mdr.img ca. 251 MB. So the absolute file size shouldn't be the problem. Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Peter Am 20.04.2011 21:38, schrieb Carlos Dávila: > El 20/04/11 12:00, Marko Mäkelä escribió: >> On Wed, Apr 20, 2011 at 11:28:31AM +0200, Carlos Dávila wrote: >>> MapSource crashes if I try to activate Spain map generated with r1919 >>> throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. >> This is the likely culprit: >> >> >> r1919 | steve | 2011-04-19 22:58:31 +0300 (Tue, 19 Apr 2011) | 3 lines >> Changed paths: >> M /trunk/src/uk/me/parabola/imgfmt/sys/ImgHeader.java >> >> Re-write "partition" size to follow the standard >> CHS algorithm as opposed to my previous complete guess >> as to how it worked. >> >> >> Other changes since r1916 were my addition of some --style=route-* files >> in r1917 and r1918. > I know you are innocent Marko ;-) , but my script updates mkgmap daily > and so today it jumped from 1916 to 1919. > ___ > 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] mkgmap Exception in thread "main" java.lang.AssertionError
Hello
Here is a new patch. I have reproduced the actual error you see on a
gmapsupp of 1.2G. This patch fixes that and also the other cases I believe.
The patch still has the debugging in. If it still fails, could you send
me the output again.
There is no need, for the purpose of testing the patch, to recompile
everything. Just "mkgmap --gmapsupp 63*.img" or similar should do.
Thanks,
Best wishes
..Steve
Index: src/uk/me/parabola/imgfmt/FileSystemParam.java
===
--- src/uk/me/parabola/imgfmt/FileSystemParam.java (revision 341)
+++ src/uk/me/parabola/imgfmt/FileSystemParam.java (revision )
@@ -1,18 +1,14 @@
/*
- * Copyright (C) 2006 Steve Ratcliffe
+ * Copyright (C) 2006, 2011.
- *
+ *
- * This program is free software; you can redistribute it and/or modify
+ * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * it under the terms of the GNU General Public License version 3 or
+ * version 2 as published by the Free Software Foundation.
- *
+ *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- *
- * Author: Steve Ratcliffe
- * Create date: 02-Dec-2006
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
*/
package uk.me.parabola.imgfmt;
@@ -25,7 +21,7 @@
public class FileSystemParam {
private String mapDescription = "Open Street Map";
private int blockSize = 512;
- private int directoryStartBlock = 2;
+ private int directoryStartEntry = 2; // Always in terms of entries of 512 bytes
private int reservedDirectoryBlocks = 202;
public String getMapDescription() {
@@ -44,12 +40,12 @@
this.blockSize = blockSize;
}
- public int getDirectoryStartBlock() {
- return directoryStartBlock;
+ public int getDirectoryStartEntry() {
+ return directoryStartEntry;
}
- public void setDirectoryStartBlock(int directoryStartBlock) {
- this.directoryStartBlock = directoryStartBlock;
+ public void setDirectoryStartEntry(int directoryStartBlock) {
+ this.directoryStartEntry = directoryStartBlock;
}
public int getReservedDirectoryBlocks() {
Index: src/uk/me/parabola/mkgmap/combiners/FileInfo.java
===
--- src/uk/me/parabola/mkgmap/combiners/FileInfo.java (revision 1870)
+++ src/uk/me/parabola/mkgmap/combiners/FileInfo.java (revision )
@@ -281,15 +281,16 @@
}
/**
- * Get the number of blocks required at a particular block size.
- * Each subfile will need at least one block and so we go through each
+ * Get the number header slots (512 byte entry) required to represent this file
+ * at the given block size.
+ * Each sub-file will need at least one block and so we go through each
* separately and round up for each and return the total.
*
* @param blockSize The block size.
- * @return The number of blocks that would be needed for all the subfiles
+ * @return The number of 512 byte header entries that are needed for all the subfiles
* in this .img file.
*/
- public int getNumHeaderSlots(int blockSize) {
+ public int getNumHeaderEntries(int blockSize) {
int totHeaderSlots = 0;
for (int size : fileSizes) {
// You use up one header slot for every 240 blocks with a minimum
@@ -301,9 +302,14 @@
}
/**
- * Get the number of blocks at the given block size. Note that a complete block is
- * always used for a file.
+ * Get the number of blocks for all the sub-files of this file at the given block size.
+ * Note that a complete block is always used for a file.
+ *
+ * For TYP files and other files that do not have sub-files, then it is just the number of blocks
+ * for the complete file.
+ *
* @param bs The block size at which to calculate the value.
+ * @return The number of blocks at the given size required to save all the sub-files of this file.
*/
public int getNumBlocks(int bs) {
int totBlocks = 0;
Index: src/uk/me/parabola/imgfmt/sys/Directory.java
===
--- src/uk/me/parabola/imgfmt/sys/Directory.java (revision 1911)
+++ src/uk/me/parabola/imgfmt/sys/Directory.java (revision )
@@ -44,13 +44,15 @@
private ImgChannel chan;
private final BlockManager headerBlockManager;
+ private final int startEntry;
private long startPos;
// The list of files themselves.
private final Map entries = new LinkedHashMap();
- Directory(BlockManager headerBlockManager) {
+ Directory(BlockManager headerBlockMan
Re: [mkgmap-dev] Error on MapSource with r1919
Hello > and out. All fine, but as soon as you select one tile Mapsosurce crashes. Ahh, that is a useful observation, thanks. > Just another thought ... could it be that C/H/S information should be > calculated dynamically based on the actual size of a .img-file? > Maybe this could save memory on a GPS when the tiles are loaded ... this > is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;) I'll see what it would take to get the size into the header. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap Exception in thread "main" java.lang.AssertionError
done with the path and the last data. create header 512 dir: header blocks(slots) 4 dir: headerBlocks 7 header blocks needed 1 dir: end slot 7 file size in blocks 18 bs 512: tot blocks 1778759, tot header blocks 7766 bs 1024: tot blocks 889549, tot header blocks 2037 bs 2048: tot blocks 444934, tot header blocks 559 bs 4096: tot blocks 222633, tot header blocks 166 bs 8192: tot blocks 111473, tot header blocks 55 bs 16384: tot blocks 55890, tot header blocks 21 bs: 16384 reserve blocks 22 create header 16384 dir: header blocks(slots) 693 dir: headerBlocks 22 header blocks needed 1 dir: end slot 704 file size in blocks 55912 Looks like gmt thinks the gmpasupp.img file is ok now. gmt v0.4.2.1891n (C) AP File: gmapsupp.img, length 916062208 Header: 27.03.2011 21:09:23, DSKIMG, xor 00h Mapset: OSM street map Map length s-f CPprio PID FID name MAKEGMAP MPS 7331 1 70013001 MPC 11863279 5 1252 10 1 6324 aio-germany 70013002 MPC 7722136 5 1252 10 1 6324 aio-germany 70013003 MPC 8287687 5 1252 10 1 6324 aio-germany 70013004 MPC 3088997 5 1252 10 1 6324 aio-germany 70013005 MPC 10022578 5 1252 10 1 6324 aio-germany 70013006 MPC 9407031 5 1252 10 1 6324 aio-germany 70013007 MPC 4810454 5 1252 10 1 6324 aio-germany 70013008 MPC 7050187 5 1252 10 1 6324 aio-germany 70013009 MPC 4655004 5 1252 10 1 6324 aio-germany 70013010 MPC 10110359 5 1252 10 1 6324 aio-germany 70013011 MPC 9882745 5 1252 10 1 6324 aio-germany 70013012 MPC 5809815 5 1252 10 1 6324 aio-germany 70013013 MPC 7314542 5 1252 10 1 6324 aio-germany 70013014 MPC 10139948 5 1252 10 1 6324 aio-germany 70013015 MPC 10299922 5 1252 10 1 6324 aio-germany 70013016 MPC 3986880 5 1252 10 1 6324 aio-germany 70013017 MPC 5803073 5 1252 10 1 6324 aio-germany 70013018 MPC 5055112 5 1252 10 1 6324 aio-germany 70013019 MPC 9651305 5 1252 10 1 6324 aio-germany 70013020 MPC 6649370 5 1252 10 1 6324 aio-germany 70013021 MPC 11272425 5 1252 10 1 6324 aio-germany 70013022 MPC 5062433 5 1252 10 1 6324 aio-germany 70013023 MPC 8873107 5 1252 10 1 6324 aio-germany 70013024 MPC 7342465 5 1252 10 1 6324 aio-germany 70013025 MPC 3388983 5 1252 10 1 6324 aio-germany 70013026 MPC 4983741 5 1252 10 1 6324 aio-germany 70013027 MPC 7368729 5 1252 10 1 6324 aio-germany 70013028 MPC 6965455 5 1252 10 1 6324 aio-germany 70013029 MPC 6410220 5 1252 10 1 6324 aio-germany 70013030 MPC 5636189 5 1252 10 1 6324 aio-germany 70013031 MPC 9420624 5 1252 10 1 6324 aio-germany 70013032 MPC 3196759 5 1252 10 1 6324 aio-germany 70013033 MPC 7374193 5 1252 10 1 6324 aio-germany 70013034 MPC 12464019 5 1252 10 1 6324 aio-germany 70013035 MPC 5463839 5 1252 10 1 6324 aio-germany 70013036 MPC 10269791 5 1252 10 1 6324 aio-germany 70013037 MPC 4569239 5 1252 10 1 6324 aio-germany 70013038 MPC 10134348 5 1252 10 1 6324 aio-germany 70013039 MPC 8020452 5 1252 10 1 6324 aio-germany 70013040 MPC 7033311 5 1252 10 1 6324 aio-germany 70013041 MPC 8808056 5 1252 10 1 6324 aio-germany 70013042 MPC 7395719 5 1252 10 1 6324 aio-germany 70013043 MPC 7717843 5 1252 10 1 6324 aio-germany 70013044 MPC 8378893 5 1252 10 1 6324 aio-germany 70013045 MPC 3342838 5 1252 10 1 6324 aio-germany 70013046 MPC 4186971 5 1252 10 1 6324 aio-germany 70013047 MPC 6516801 5 1252 10 1 6324 aio-germany 70013048 MPC 12109811 5 1252 10 1 6324 aio-germany 70013049 MPC 6723966 5 1252 10 1 6324 aio-germany 70013050 MPC 4775971 5 1252 10 1 6324 aio-germany 70013051 MPC 5672470 5 1252 10 1 6324 aio-germany 70013052 MPC 3275655 5 1252 10 1 6324 aio-germany 70013053 MPC 5504591 5 1252 10 1 6324 aio-germany 70013054 MPC 5303348 5 1252 10 1 6324 aio-germany 70013055 MPC 4926646 5 1252 10 1 6324 aio-germany 70013056 MPC 4921551 5 1252 10 1 6324 aio-germany 70013057 MPC 7033442 5 1252 10 1 6324 aio-germany 70013058 MPC 5454211 5 1252 10 1 6324 aio-germany 70013059 MPC 7411835 5 1252 10 1 6324 aio-germany 70013060 MPC 10925688 5 1252 10 1 6324 aio-germany 70013061 MPC 6273453 5 1252 10 1 6324 aio-germany 70013062 MPC 6625342 5 1252 10 1 6324 aio-germany 70013063 MPC 9190760 5 1252 10 1 6324 aio-germany 70013064 MPC 8737179 5 1252
Re: [mkgmap-dev] Merge areas
> I plan to add an R*-tree to get a better performance in the locator > branch. Maybe this might be reused. > If someone (Daniel?) likes to implement the R*-tree please lift your > fingers. I am not very keen on doing this and it would help a lot! > Have you looked around, if there is some implementation already available? At a quick search I have found some interesting projects: http://www.rtreeportal.org/code.html seems to have a small use ready R*-tree project. Not sure about the license. http://www2.research.att.com/~marioh/spatialindex/ looks more overloaded with unneeded features. http://en.giswiki.net/wiki/JSI_%28Java_Spatial_Index%29_RTree_Library is an open source project. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap Exception in thread "main" java.lang.AssertionError
Hi > Looks like gmt thinks the gmpasupp.img file is ok now. Great, I'll tidy the patch up and commit it in a day or so, if there are no problems. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Merge areas
> >> I plan to add an R*-tree to get a better performance in the locator >> branch. Maybe this might be reused. >> If someone (Daniel?) likes to implement the R*-tree please lift your >> fingers. I am not very keen on doing this and it would help a lot! >> > Have you looked around, if there is some implementation already available? > At a quick search I have found some interesting projects: > > http://www.rtreeportal.org/code.html seems to have a small use ready > R*-tree project. Not sure about the license. > > http://www2.research.att.com/~marioh/spatialindex/ looks more overloaded > with unneeded features. > > http://en.giswiki.net/wiki/JSI_%28Java_Spatial_Index%29_RTree_Library is > an open source project. Hi Johann, thanks for your query. If found the first two projects myself. The source code is quite old stylish and lot of work seems to be necessary to use the two projects. But the third one looks like a perfect match! 1. The project is alive 2. The R-Tree is completely kept in memory 3. It's open source and the licence should be ok for us After a first short try I got some exceptions with the R-Tree but I think these are little problems that can be fixed. Thanks for hint!! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
