Am 08.03.2011 02:00, schrieb garvanmaew:
On Tue, 2011-03-08 at 07:57 +0700, garvanmaew wrote:
On Tue, 2011-03-01 at 20:14 +, Steve Ratcliffe wrote:
Hello
BUILD FAILED
/Users/railrun/Downloads/osm/mkgmap/build.xml:212: Warning: Could not
find
resource file
On OSX 10.6.8 you have
Apache Ant(TM) version 1.8.2 compiled on December 20 2010
and
java version 1.6.0_22
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
So compiling the splitter svn/Trunk works.
But i need
Version 1890 was commited by steve on 2011-03-08 09:51:01 + (Tue, 08 Mar
2011)
Fix for ant 1.8 build when the protobuf jars do not exist.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 08/03/11 06:23, Kolesár András wrote:
There is code that can read from the .img file. It currently only
reads lines and points but could be extended to read polygons too.
See MapReader and in particular RGNFileReader. I realise this is a
much bigger task and probably slower.
I have
On Tue, 2011-03-08 at 09:51 +, svn commit wrote:
Version 1890 was commited by steve on 2011-03-08 09:51:01 + (Tue, 08 Mar
2011)
Fix for ant 1.8 build when the protobuf jars do not exist.
___
Thank you, Garvan
Hi
But i need help with this
http://svn.parabola.me.uk/splitter/branches/crosby_integration/
How can help ?
That branch is now finished as it was merged into the trunk recently.
A useful next step would be for splitter to output pbf format files.
pbf files are:
- smaller
- faster to read
A few remarks:
The Typ file is not registered in mapsource (I think someone already mentioned
it, but it is quite urgent to repair this)
I dont know where to find / how to access the installer templates. Do I have to
compile mkgmap for this?
Another thing on the wishlist is to add support for
Am 08.03.2011 12:16, schrieb Marko Mäkelä:
On Tue, Mar 08, 2011 at 10:00:22AM +, Steve Ratcliffe wrote:
pbf files are:
- smaller
- faster to read (and write?)
- already understood by mkgmap
- readable by Osmosis (the 0.5 XML produced by splitter is not)
You can read 0.5 XML with osmosis
Hi,
I tried out the overlays file and came across the following problem:
Without overlays roundabouts look different from the normal street types
because e.g. my highway=secondary (0x04) is yellow but
junction=roundabout has to be 0x0c which is white in my typ file.
To change that I tried this:
I'm not sure but maybe the code 0x11f02 isn't supported?
I used to do the same with roundabouts but I named it 0x0c04,
in my overlays file:
0x0c04: 0x0c, 0x04
This was routing fine.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Ralf Kleineisel schrieb am 08.03.2011 18:09:
Lines file:
junction=roundabout highway=secondary [0x11f02 road_class=2
road_speed=3 level 4]
Overlays file:
0x11f02: 0x0c, 0x04
Then I created a test typ file with a very broad pink 0x0c just to see
if the two lines are really there. They
Torsten Leistikow (de_m...@gmx.de) wrote:
Ralf Kleineisel schrieb am 08.03.2011 18:09:
Lines file:
junction=roundabout highway=secondary [0x11f02 road_class=2
road_speed=3 level 4]
Overlays file:
0x11f02: 0x0c, 0x04
Then I created a test typ file with a very broad pink 0x0c just to see
Forget the overlay crap and use continue (makes no sense to have two
routable lines with the same road_class/road_speed anyhow).
On 08.03.2011 18:09, Ralf Kleineisel wrote:
Hi,
I tried out the overlays file and came across the following problem:
Without overlays roundabouts look different
On 3/8/2011 6:14 AM, Minko wrote:
A few remarks:
The Typ file is not registered in mapsource (I think someone already
mentioned it, but it is quite urgent to repair this)
I dont know where to find / how to access the installer templates. Do I have
to compile mkgmap for this?
Another thing
PS
Those two lines were missing:
WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
$INSTDIR\$x.TYP
DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
typfile=x.typ
___
mkgmap-dev mailing list
Hi,
Thanks to Thorsten and Minko for they report about the TYP file issue.
It also looks like I overlooked the index files so in the current
mkgmap, the registry keys for the MDX and MDR files will be created
regardless of those files actually existing.
This was an easy fix and attached is
El 08/03/11 23:07, WanMil escribió:
Next round of the location improvements:
* The algorithm that searched which elements were contained within a
boundary was (is) wrong. I updated some parameters in the Quadtree so
I the probability is very much lower that an element is not assigned
17 matches
Mail list logo
