Re: [mkgmap-dev] [PATCH] - Code for Highway Symbols
On Mon, May 18, 2009 at 07:47:23AM +0200, Thilo Hannemann wrote: Attached is a patch by Toby Speight that allows to insert the code for highway symbols. I'm using it since a while with no adverse effects. Is there any chance that it gets integrated into trunk? Or if there is a problem with that code, what should be changed in order to make if fit for integration? Thanks for reminding me about this, I'll look back over the discussion and apply it soon. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi Thanks for working out what goes wrong with very small maps. Although you are correct that the overview map only contains area definition and background polygons which should not be dropped, in the future the overview map should contain real map features so it might be best to specifically exclude those polygon types. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Performance
Hi Richard I'm currently trying to create a map from a GB planet extract, and performance seems much slower than I remember. I've split the extract into six parts with splitter.jar (I'm using some big route relations so can't split it any further). The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal? It takes just under 4 minutes for me to do the GB extract split into 13 pieces with routing. So after an hour I'd imagine something is wrong. The style file is reasonably complex and contains numerous 'set' instructions, plus a handful of relation 'apply's. My system is an Intel Mac mini, OS X 10.5, 1Gb. A number of people run fairly complex styles, but still it could be a bug that is only shown with your style though. If you could send me it I will look at it and see if it is the problem. The only non-bug thing I can think of is the memory given to java. If you give an amount that is just not quite enough, it can slow the run down dramatically. That would be pretty unlucky though, normally it would work or you would run out of memory within a few minutes. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Performance
Hi On Sun, Jun 28, 2009 at 08:52:03AM +0100, Richard Fairhurst wrote: I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter which suggest The default [for max-nodes] is fairly conservative, I think you could increase it quite a lot. Clearly not by 50% though. ;) Yes that seemed to be true at the time. It all depends on the number of those nodes that are going to be displayed and the ratio of nodes to ways. To remain even slightly accurate across all parts of the world as more gets added to OSM it will probably have to look at the tags and the style to approximate better how much space will be needed. What that does mean is that I'll need to write a relation splitter, as the whole reason I'm doing this is to show cycle routes, and two of them have bitten the dust (too many tiles) even on the default split. I presume there isn't one already out there? When I get the time (which should be next week) I will re-write splitter to remove the limitation of 4 tiles per relation or way. And try to improve the size estimate too. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Transliteration and lower-case
Hi Ivan I downloaded fresh r1067. Unpacked it new directory, cleaned up mapsource registry, etc.. added attached files (reg, cmd file renamed to .txt and xml file to fetch OSM data) and I still get lower case letters in resulting .img file I ran the commands in your script to download the file and generate the maps. I see lowercase characters in MapSource for the -INT map. But only when viewed in MapSource, the names inside the file are only in uppercase and are shown in upper case in other programs such as QLandkarte. The code-page 1251 one I see uppercase letters in MapSource. Sorry if this is what you meant all along. That is the way that MapSource works and as far as I know there is nothing much that can be done about it. If anyone knows a way, then let me know. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Questions related to practical usage of MKGMAP
On Wed, Jul 01, 2009 at 06:13:27PM +0200, Clinton Gladstone wrote: Let us know if this is enough information for you. If not, I can send you the patches and further information directly. I know have a fair amount of time to work on mkgmap and applying these pathes is going to be one of the first things I do as it is a pretty neat feature. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Memory limits for mkgmap and splitter
Hi Could you please tell me which Map would have to be reimplemented? There was a lot of changes (and file deletions) since version 3. Yes, it is completely different code. The original code (r3) did nothing except attempt to save the nodes to a berkeley db. I then gave up on it and wrote the current code that uses an open hash map. Could you explain why you write that There is a maximum of 255 output files. This should anyway be enough with the current amount of data. ? Well at the time europe was about quarter of the planet file and took about 60 tiles, so probably about enough to any area of interest and perhaps even the whole planet. This was without routing which currently requires smaller tiles. Also the data is growing fast, and so it is certainly not true any more. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1073: Add highway shields and other ways of modifying values in the style files.
As roads can have up to 4 labels we could set one of the labels to be the original road name and then the searching would work as before. The problem now is that by altering the name in the style file we lose the original name. Something to ponder. Funnily enough I was just adding the ~[0x##] notation to the polish reader and saw that my test file had Label and Label2 where Label had the name and Label2 contained the reference and shield. So I was already pondering... So I agree we should split the name and the ref into 2 different labels. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recommended stable version?
Hi On Sun, Jun 28, 2009 at 08:26:33AM +0200, Nop wrote: According to the Wiki page, the last version recommended as reasonably stable is 858. As I needed some particular improvements, I am using Yes 858 is now ancient. I think it doesn't even do routing with OSM input files. might in order but quite a number of the posts here seem to indicate that many things are very experimental so this might be a change for the worse at the moment. My map is not intended for routing, so will not I think most of the so-called experimental things have to be turned on with an option. So the question is: Are there any plans to work towards another recommended reasonably stable version? Or do any of you have a personal recommendation for a build that in your experience should not cause trouble? I've always tried to keep the main trunk as stable as possible and the so called stable release is just one that is not too soon after some major new thing has gone in. The Computerteddy maps are usually made with pretty much the latest version, so if there are basic problems they get noticed pretty quickly. I think we should set the new version to 1067 which is before some recent changes went in. If there is a major problem, I will fix it and update. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Hi
And I think, if I would change the second line to
highway=* tag_a!=yes {set tag_b=yes}
adding in the missing '' sign:
highway=* tag_a!=yes {set tag_b=yes}
Then that is allowed, and the result would still be that all
highways were 0x01.
it wouldn't change anything, or would it?
What would happen, if the second lien would be changed to the following:
tag_a!=yes {set tag_a=no; set tag_b=yes}
You cannot set the same tag that you are matching. (Currently there is
a bug and it will hang, but the intended result would be just that it is ignored
as it is too late.)
All actions will be run before the final matching rule is selected and the
action rules are not run in any particular order. So anything that relies
on the order of the action rules will not work reliably.
So basically I am trying to use the action rules as a preprocessor for
the OSM data.
So yes, could you think of what kind of preprocessing rules you want
and then we can either make the existing system do that or have a
separate pre-processing phase for that.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Hi http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/network/ http://www.openstreetmap.org/user/Richard/diary/6949 Looks great! Is there anything that you would really like it to do that it doesn't yet? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] some natural points
Hi Marko, I have applied your patch from Ben's updated patch and made your changes. Hope that is all correct, could you check please. Thanks, ..Steve I compared your patch to mine. I only noticed two differences: First, in my patch, truck stops have precedence over manned fuel stations (to make the map more useful to truck drivers): +amenity=fuel fuel:HGV_diesel=yes [ 0x2f16 resolution 19 ] amenity=fuel shop=convenience [ 0x2e06 resolution 19 ] I may have posted an initial version of the patch where this was not the case. Second, in my patch, natural=rock is added before natural=spring, not after it. It is a cosmetic thing (maintaining alphabetical order). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] some natural points
Hi I tried to compile a test map to go trough POIs on my eTrex legend. java -Xmx512m -jar mkgmap.jar test-map:all-elements provides me just with a list of errors: Can't set city point index for 0x10,0x22 (too many indexed points in division) Can't set city point index for 0x10,0x23 (too many indexed points in division) .. etc. That used to happen several versions ago, are you sure that you are running an up to date version of mkgmap? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Leisure Barrier at same times
Hi David I produce a map from Geofabrik Ireland file. I discovered that Saint Stephen's Green park in the Dublin city center is not well rendered (in the past it was OK). It looks like a polygon on OpenStreetMap.org but if you take a look in data, it is both a barrier=fence (rendered with the undefined polyline type 0x33) and a leisure=park (polygon type 0x17). How can I force to render the park at least as a polygon and not only like undefined polyline ( without removing the barrier rule in lines style) ? NB : if I remove manually the tag barrier, the polygon is well rendered. Does it mean I found a bug or does it mean data should not be defined both like polyline and polygon in OSM ? Currently lines have priority over polygons, so what you are seeing is to be expected given the data. We could reverse this, but that may introduce the opposite problem. I wouldn't use the same way for two different things, but If that is what people do commonly then I guess we will have to try and deal with it. It is a similar problem the boundary and road problem that was discussed a while ago. Currently the polygon and line rules are not kept separately, but I suppose I could separate them and run against them both. Its a bit of a waste for something that will be fairly rare though. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] show oneway streets (and other mapping information)
In my previous post i proposed a patch that solve this problem but it is still not observed nor committed. I don't know why? :( Sorry about that, I think that the patch is good, I've been busy with other things in last few months, but I should have more time soon. Also the ordinary mapnames do not have to be integers either, not just the overview name. So I'd like the patch to be extend to cover all names. And it would probably be a good idea to make a MapName object to keep the name and number together. I'll commit the patch as it is now. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Since no one replies to my mail, I'll do it myself ;) Thanks for studying the problem so closely - it is very useful. What I found is the following. Splitting a file with a border will produce a file that has the exact bounds, without the overlap, in the resulting map. That is intentional; the bounds should not overlap and should meet exactly. There is extra data in the file that extends beyond the bounds and mkgmap should cut the lines at exactly the bounds. Cutting the lines at the exact boundary is bes done in mkgmap rather than splitter for several reasons, for example you have to know whether something is a line or a polygon to know what to do. Then, in addToOverviewMap, I added -1 to the minimum lat/lon values: int minLat = roundDown(bounds.getMinLat(), overviewMask) -1; int minLon = roundDown(bounds.getMinLong(), overviewMask) -1; I think that three things must line up exactly, the tiles them selves, the areas within the overview map and the areas in the TDB file. Probably one or more of those are out of step. Its also possible that it only goes wrong in certain circumstances such as +ve or -ve longitude. The next step is to find out exactly which one is wrong and compare with a working map if necessary. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
On 17/07/09 22:59, Valentijn Sessink wrote: Steve Ratcliffe schreef: That is intentional; the bounds should not overlap and should meet exactly. Are you really (as in really-really-really) sure about the fact that the Oh, I'm not usually sure about anything. I do know what you are talking about though, there have been similar before. So you will probably also find that in the area that disapears, if you hover over a road you do not also get the usual pop-up that tells you the name of the road. Anyway I'll take a look at the example you posted in another message. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change in style parser from r-1067 to r-1087?
On 19/07/09 14:30, Torsten Leistikow wrote: with mkgmap version r-1067 all my style files were ok. Now version r-1087 reports some errors. For example a ';' is not accepted any more in a tag value. I don't think a ';' has ever been allowed unless the tag was quoted. So you have to say highway='one;two' for example. If you still get the error or if that is not what you meant, could you please send the errors that you get. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change in style parser from r-1067 to r-1087?
Hi But also the following line from the style file is rejected: highway=trunk junction=roundabout access!=* vehicle!=* motorcar!=* [0x26 resolution 18] What is wrong with this line? There is a missing '' between access!=* and vehicle!=* ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
On 18/07/09 13:09, Steve Ratcliffe wrote:
Hi
I've run your example and looked at the bounding boxes of everything
important that I know about.
First the actual bounds as given in the input files.
All the bounds below I believe should be exactly equal to this.
Also the first number on the first line should be the same as the
third number on the second line bottom of 63240010 matches the
top of 63240008 (only the last four digits of the map number shown below).
0010: 52.4267578125,3.2958984375 53.6572265625,5.625
0008: 52.119140625,3.2958984375 52.4267578125,4.9658203125
Inside the overview map there are definition areas that should cover the
individual maps.
0010: 52.470703,3.339844 53.701172,5.668945
0008: 52.163086,3.339844 52.470703,5.009766
So top matches bottom, but not the same as the bounds.
This could explain mapsource, but as it is not used
on the device can't explain the problem in the GPS.
So I know why this happens now.
Coordinates in the file are recorded by using an offset from a central
point in a subdivision. The central point is recorded exactly but
the offset is in multiples of 2048 map units (in this case - it depends
on the zoom level). This is called a 'shifted unit' elsewhere so that
is the term I will use here.
So if the tile height or width is an odd number of these shifted units
then the centre point will be half way between a shifted unit boundary.
Therefore adding any offset will leave you half a shifted unit out.
I'm not sure if I explained that very well, but my conclusion is
that
1. The tiles produced by splitter should be aligned on an even lower
zoom boundary, so that they will be an even number of units on the
overview map.
2. This is probably a problem throughout elsewhere. The central point
should probably always be on a shifted unit boundary.
A quick test with the attached patch shows that the boundaries shown in
mapsource now line up with the map. The places where there are no
tool-tips near the boundaries still exist though. I've not tried
routing to see if it makes a difference.
The attached patch is not a fix to the problem.
..Steve
Index: src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
(revision 1088)
+++ src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
(working copy)
@@ -45,7 +45,7 @@
// TODO need to change this.
private final int topLevel = 5;
- private final int topBits = 14;
+ private final int topBits = 15;
/**
* This is a fake source of data and is not read from a file, so always
@@ -132,6 +132,7 @@
* @param shape The polygon to add.
*/
public void addShape(MapShape shape) {
+ System.out.printf(shift for overview + getShift());
mapper.addShape(shape);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: --TDB option for ways only map doesn't show up in 6324000.img
My problem is that if laurels8.mp contains a full set of contours, hydrography and land cover my 6324000.img file shows a corresponding 07250732 quadrangle, but if laurels8.mp consists only of ways, there is no quadrangle for 07250732. Therefore, while I can see the ways in MapSource, I can’t use MapSource to select the ways only maps to combine with my other maps. I think that this is expected for transparent maps. As far as I understand it you cannot select anything that does not have a polygon behind it so your land use polygons, so I'm guessing your land use polygons are allowing you to select the ways in the first example. Transparent maps don't have a background polygon so you can't select anything from them normally. So I think that is just how it works and there is nothing we can do about that. If anyone knows any different though, please shout up! ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline not supported?
And when I look to the Coast, I'll not see Water. Are there People working on that? As far as I know, no one is working on creating sea polygons. It would be a very useful feature if anyone want to step up and do it. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] proposed README organization
receiving some off-list encouragement to do so. Here's a patch which adds a README.INDEX that describes multiple readme files. If people Besides what I listed below, I think we need a README that explains to a newbie: if you want to make an img from osm data to use, what options should you use and why. Plus probably ones that explain how to get maps into MapSource and RoadTrip. Comments welcome. Looks good to me. Thanks ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi // TODO need to change this private final int topBits = 15; the first level in the overview map? If so, then could it not be read directly from the detailed maps, rather than being a constant? I noted the TODO. Yes that is exactly right. It should be calculated so that the whole area covered by all the maps can be represented by a single area. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Properly remove spaces in highway shield labels
On 21/07/09 00:35, Clinton Gladstone wrote: I found that highway names with spaces in them, such as A 1 would be displayed in the shield as just A. Thanks, looks like a bug to me. I will commit your fix and a test for it. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter - performance and memory
On 19/07/09 23:58, Chris Miller wrote: Good news - with my changes the areas.list file was generated fine, peaking at maybe a 3GB heap. Cool. It is also worth noting something that osmcut (an other map splitter) does. It has two modes; one where a map is used for when the input file is small and another where a list is used and the node-id is the index into the list. The later is used for splitting the whole planet file. The second method uses less memory where the memory wasted by node-ids that are not in use is less than the amount of memory used by storing the node-id plus the memory wasted in free space in the hash maps. As currently most nodes are used (about 88%) this is a big win on the whole planet file, while still giving access to the node ids. I've committed the patch. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter - performance and memory
Hi Chris On 22/07/09 12:17, Chris Miller wrote: 1) If a way covers more than one area, should ALL nodes for the way belong to all of those areas, or should each area only contain the nodes that lie within it, regardless of ways? Currently the latter seems to be the case but that feels wrong to me. You need at least one node outside the area for each time a way crosses the boundary, so that mkgmap can cut the way on the boundary. Or else you need to manufacture the nodes that sit exactly on the boundary yourself. The later option is practically not possible(*) as you need to know if something is a line or a polygon to do it correctly. The current splitter works by including all nodes in an extended area and letting mkgmap split the ways on the declared boundary. So it could fail if the spacing between nodes is larger than the extra overlaping area. Fortunately, large node spacings are impractical for all sorts of tools so don't occur much. 2) Does the XML have to contain nodes first, then ways, then relations, or can they be intermingled? (I think osmcut produced files like this) If it is permitted, what are the consequences of intermingling them for other tools etc? I know that as it stands splitter.jar expects them to be in node/way/relation Well for maximum compatibility they should be in that order. Splitter doesn't actually require them to be in that order, as long as nodes occur before the ways that need them. I added this because there is some software that intermingles them like that. (*) I am considering being able to read a style file into splitter so that you could much more accurately estimate the size of the resulting files. In which case you could know if a way was a polygon in the given style. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] vanishing map
Hi
Could everyone who is interested in this please try the attached patch.
It seems to work on the example I was looking at, but of course problems
may just have moved elsewhere so please check thing are OK
more widely. It would be good to know if it makes a difference to
inter tile routing as well.
..Steve
Index: src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java
===
--- src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java (revision 988)
+++ src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java Wed Jul 29 10:53:31 BST 2009
@@ -96,15 +96,16 @@
this.zoomLevel = z;
int shift = getShift();
+ int mask = getMask();
this.latitude = (area.getMinLat() + area.getMaxLat())/2;
this.longitude = (area.getMinLong() + area.getMaxLong())/2;
- int w = (area.getWidth() + (1shift)) / 2 shift;
+ int w = (area.getWidth()/2 + mask) shift;
if (w 0x7fff)
w = 0x7fff;
- int h = (area.getHeight() + (1 shift)) / 2 shift;
+ int h = (area.getHeight()/2 + mask) shift;
if (h 0x)
h = 0x;
@@ -167,6 +168,16 @@
}
/**
+ * Get the shift mask. The bits that will be lost due to the resolution
+ * shift level.
+ *
+ * @return A bit mask with the lower ishift/i bits set.
+ */
+ public int getMask() {
+ return (1 getShift()) - 1;
+ }
+
+ /**
* Get the resolution of this division. Resolution goes from 1 to 24
* and the higher the number the more detail there is.
*
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
Hi And in my style the lines-file contained the following rules: highway=null_null layer0 [0x01 resolution 10] highway=null_null layer=0 [0x02 resolution 10] highway=null_null layer0 [0x03 resolution 10] highway=null_null layer='-1' [0x04 resolution 10] highway=null_null layer='0' [0x05 resolution 10] highway=null_null layer='1' [0x06 resolution 10] highway=null_null layer='+1' [0x07 resolution 10] highway=null_null [0x08 resolution 10] As a result I expected the following conversions 9902 - 0x01 9912 - 0x02 9922 - 0x08 9932 - 0x03 9952 - 0x03 Against my expectations the conversions were the following: 9902 - 0x03 9912 - 0x05 9922 - 0x08 9932 - 0x03 9952 - 0x03 I've just written a test to duplicate this problem. I see the first unexpected result, but the not the second (9912). I suspect the first is just that negative numbers are not recognised. I would say that the second result would be very strange as the rules for 0x2 and 0x5 are exactly the same and the 0x2 one comes first and so should win. What is wrong? - My understanding of the style rules? - The documentation of the style rules? - The behaviour of mkgmap? The behaviour of mkgmap. But could you re-check the 9912 result as that one works as I (and you) would expect for me. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
On 29/07/09 20:53, Torsten Leistikow wrote: Steve Ratcliffe schrieb: I would say that the second result would be very strange as the rules for 0x2 and 0x5 are exactly the same and the 0x2 one comes first and so should win. You 're right, I have to apologise for mixing the numbers. OK, I've just committed a fix. Do you agree all is well with it? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Translating command line strings into target charset
Hi I know it was quite a while back when you posted this, sorry. On 24/06/09 21:56, Marko Mäkelä wrote: My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set problem in a tile name of my map. I wasn't aware of the problem, because my Edge 705 does not display map tile names. The tile Etelä-Suomi (Southern Finland) appears as Etelä-Suomi, where the currency symbol ¤ is displayed as a black diamond. Other ä characters in the gmapsupp.img are encoded as the byte code 304 in octal notation. Yes it just slaps in the string directly without translation. It appears from your example that it is being displayed as a latin1 character set. I don't know what controls that though; does it take the character set from the LBL section or is there something else. A safe first step would be to transliterate to ascii which works over the widest range of languages in mkgmap. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Magic highway symbols on Vista CX failing
Hi I did not. If I do, the symbols appear correctly. I'm not familiar with neither the Garmin encoding nor mkgmap's handling of it, but would it be possible to add the codes for the symbols to the names in a way that they work with both 6bit and 8bit encoding? Sure it just looks like a bug. I've just commited a fix, try version r1116 and see if that is any better. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with styles
*G:\Willem\Mijn documenten\mkgmap\mkgmapr1117java -jar mkgmap.jar --style-file=fietskrt fiets2.osm* If your style is zipped as attached to your message then you need to give the full name fietskrt.zip Does that help? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] compiled mkgmap binary with contour option
Hi On 06/08/09 13:56, maning sambale wrote: According to this: http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage#Contours Contours were added in r1079. They were removed in r1080 as they do not compile without extra packages. There are several different input file formats supported. I believe that all the ones that do not need the external library are compiled in the latest version and the only one missing is for aster. I am not an expert on the contour formats so someone please correct me if I am wrong. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - styling for the power user
Hi macro/programming language. As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that? The style system was designed to do the little things that were hardwired into the code directly from the style itself. It also pretty much pre-dated routing so that the fact that you can have two separate names for a road (say a name and a reference when both exist) cannot be implemented. I would like to know what people want to do that is not possible. Is anyone other than Felix doing something that is difficult with the current system? Then I need to work out if the main problem is that actions are, in effect, run in a random order. Would guaranteeing that actions were run in the order that they occurred in the file help? It would certainly make it possible to work out what a set of rules did. I probably shouldn't have allowed stand alone actions on rules without a type, without also making them ordered. I think it can be done without a large performance overhead (at least if you make minimal use of actions), but if it is not going to help any power stylers then it is not worth doing and we should do something else instead. implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could invoke the plug-ins that one would like to use. I remember thinking that a style could have a classes directory probably for type resolvers although I forget exactly why. It would certainly be possible, although I would like to see if can make the current system work better for people. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Append Name with general rules via style-file
With these two rules, even if they are run in same order as
they are written, the second one could never
have an effect if ${name} is defined.
highway=* { name '${name} (${ref})' | '${ref}' | '${name}' }
highway=* { name '${name} ${name1}' | '${name1}' | '${name}' }
This is because you can only set the name once. If ${name} is set
then the name will be set in the first rule and so the only
way that the second rule can be used is if ${name1} is set and ${name}
is not set.
You could fix that by doing everything together, if that is
the effect you want:
highway=* {
name '${name} (${ref})'
| '${ref}'
| '${name} ${name1}'
| '${name1}'
| '${name}'
}
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Append Name with general rules via style-file
Hi Felix
highway=* {
name| '${ref} ${name} ${name1} ${name2}'
| '${name} ${name1} ${name2}'
| '${ref} ${name1} ${name2}'
| '${ref} ${name} ${name2}'
| '${ref} ${name} ${name}1'
| '${ref} ${name}
| '${ref} ${name1}
| '${ref} ${name2}
| '${name} ${name1}
| '${name} ${name2}
| '${name1} ${name2}
| '${name}'
| '${name1}'
| '${name2}'
| '${ref}'
}
In this case you could give each value a default value of nothing, so
it would always match with just the one rule
{ name '${ref|def:} ${name|def:} ${name1|def:} ${name2|def:}' }
But you would get extra spaces when any of the value were empty.
You should also be able to do this to append any number of things
with only one line for each thing to be appended:
highway=* {
set fullname='';
set fullname='${ref}';
set fullname='${fullname} ${name}';
set fullname='${fullname} ${name1}';
set fullname='${fullname} ${name2}';
name '${fullname}';
}
But I see that didn't work because of a bug. That is now fixed and
so the example will build up a string with spaces only where needed.
The only problem would be that if ref doesn't exist, then there
will be a space at the start. I can't see a way around this
at the moment, but we could add something for that.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1125: Ant task for mkgmap
On 09/08/09 13:25, Christian Gawron wrote: Thanks for adding the Ant task! No problem. I am going to change though it so that it doesn't require making a bunch of methods public on the command line reader. Maybe it's a good idea to move the GeoTIFF stuff in the extra-dir, too. Yes, that is the plan. And then I will eventually compile the nightly builds against the needed libraries, so no special build is required as long as you have the needed libraries. You always will have for ant. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Multipolygons
Hi I am going to merge all the multipolygon fixes. Including, if appropriate, the sea polygon changes. In addition to the patches sent to the list I also have permission to use the attached patch from Olaf Kähler which he describes as follows: I guess, mkgmap has a bug with vanishing islands in case of multipolygons. The major problem seems to be, that in the polygon splitting process (PolygonSplitterBase.java), the Java awt methods mess around with the inner polygons, that were previously merged into the outer polygons. I included a patch, that somewhat works, but still seems to have a few issues. I've also included sample .osm files to explain these issues: I'd appreciate it if anyone who understands the polygon issues takes a look at the patch. Also if you have an test cases which don't work with the current trunk but might be fixed by the outstanding patches let me know. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suggestions: improvements to mkgmap --style-file= and --list-styles options
On 09/08/09 18:41, Charlie Ferrero wrote: 1. Currently, if you invoke mkgmap with the --style-file= tag and point to a non-existent style file (or incorrect path), mkgmap continues regardless (and applies the inbuilt default style, afaict). Can I suggest a patch to mkgmap that at least makes it clear that no style file was found in this circumstance? Sadly I lack the programming skills to do this, but hopefully it's a relatively trivial thing to change. Yes this should be done. It has been requested once or twice before. 2. Secondly it seems to me that mkgmap has three inbuilt styles (default, noname, test) that you cannot change by editing the files in the resources folder. Yes that is right. The resource directory is effectively source code and perhaps shouldn't be included. It is not required as everything in there that is required is inside the mkgmap.jar. Its a good source of examples I guess. You have worked it out perfectly correctly; the --style-file argument is to use styles that are external to the mkgmap.jar file and so not built in. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bugreport for new splitter
Hi Good question, I was wondering that myself. It looks like with so few nodes per area, we end up with some very thin areas that for example result in the two areas on each side, plus two adjacent areas above, being included in the extended bounds/overlap if a node is in the centre of the thin area and close to the top. OK, if that is the case I was thinking that the overlap might be better as a percentage of the size of the area. In areas where there is a straight road that continues for miles and miles nodes might be widely spaced, but that is unlikely in densely mapped areas. The Garmin units have different sizes depending on direction and latitude, but 2000 is over 4km(?) and that might be too much in any circumstances. Here's an example of a node that wants to be in 5 areas: node id=447665000 lat=46.0753181 lon=13.1930056 version=1 That is an interesting area, as it appears that buildings are mapped so there is a much higher node density than normal, but only the main roads are there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygons
Of course I forgot to attach the patch and examples... trying again. ..Steve mkgmap-multipolypatch-v2.tar.gz Description: GNU Zip compressed data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bugreport for new splitter
Hi On 10/08/09 10:52, Chris Miller wrote: Given that it's only when a relatively low number is given for --max-nodes that we run into any trouble, maybe it's best to leave at 2000 for now. Is there a reason why people would want to use such a low number? Smaller tiles so more flexibility about exactly what they upload to their Garmin perhaps? Well I'm just saying that there was no particular thought in choosing 2000 in the first place. For really old devices that have limited memory you may only be able to load a few tiles at a time and then it would be more flexible to have smaller tiles. But this is really from before OSM was started, I've never had anyone complain that tiles were too big, in fact quite the opposite. So ideally you want to be able to make the tiles as large as possible. However if you only look at the number of nodes then you find that you have to have it quite low to cope with one particular area when a higher value would have been fine everywhere else. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitting multipolygons
On 10/08/09 15:07, Nop wrote: There are other outstanding mulitpolygon fixes that may help too. The first of which is applied to the multipolygon branch: I am not sure I understand. Do maps split with splitter also have the problem of missing polygons at the moment? The splitter doesn't really know about multi polygons so there are no reasons I know why it should introduce any problems. It is just the way the work is shared between splitter and mkgmap. The splitter creates a rough oversized area and mkgmap does the difficult work of cutting the polygons to the exact boundary. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Option --remove-short-arcs
Hi Is there any problem with this option, such that you might not want to use it? As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. If that is so, then we should just set the required behaviour whenever the route option is given. I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ... and a success report
On 12/08/09 15:12, Valentijn Sessink wrote: A nice success report: I built a map of Germany for my Garmin Nuvi 205 BeNeLux France. And guess what? Even inter-map-routing works! I can route from Amsterdam to an obscure place somewhere half way in Germany, without any problems. :-) So was that with --remove-short-arcs=5.4 (or 5) in the end then? And have you done previous maps of the same area that didn't work without that option? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
Sorry about previous blank email... On 12/08/09 17:13, Mark Burton wrote: What we want is that the result of RouteArc.convertMeters() is not less than 1. So with the values it has at the moment that requires a min arc length of 4.878 metres. If we set the default to 5m, we should be chuckling. OK and how about we take the opportunity to check out convertToMeters() Could anyone that has a route that they know or can measure the exact length of and compare to the length given by mapsource with an mkgmap generated map post their results to the list or to me. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r1135: Patch by Rudi for problems with multipolygons
Problem 3: Small multipolygons are rendered correctly but I have a problem with larger multipolygons. The inner holes are visible at low zoom levels, but they disappear if I zoom in. I don't know if this is a problem of the Garmin software or if this is an effect of a filter in mkgmap. Solution: Nodes with identical coordinates (where the outer way is joined with the inner way) seem to be the reason. I shift two nodes by one unit, now the multipolygon is displayed correctly if I zoom in. In the patch, this solution is applied when the number of points is less than 32. Is that an exactly determined number, or is it just a rough estimate of where things start to go wrong? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Make --add-pois-to-areas default?
On Sat, Aug 15, 2009 at 09:16:36PM +0200, Elrond wrote: In the long run, we should consider, if this should be somehow modifiable by the style. Either by letting the style say Don't go and create a POI or the other way round. It is already possible for a style to set options. All we have to do for any option that we want to allow a style to set, is to add it to the list in StyleImpl. You can also make it possible for the command line to override the option or to disallow being overriden. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r1135: Patch by Rudi forproblems with multipolygons
polygons patch of Christian. The sea polygons patch is already committed to the trunk, so I don't think it's a good idea to add version 1 of my patch to the trunk afterwards. The sea polygons patch is not in trunk as far as I know. I'd like to keep the patches separate, if you have an improved patch against the current polygon branch, then please send it. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Mark, great work on implementing the extended types. As for this problem, I don't see it. With a simple style that only includes one line type with overlays it works just fine. Same with relations. Also looking at the code change, there is nothing that appears to touch that area of the styling at all. Felix, I don't mind looking into it, but I will need a lot more information including the complete style, an input file that doesn't work and an example of a road that doesn't work in the new version. Overlays. I mean the overlays file in the style-files. Before 1139 if you had a line in your lines file saysing for example: highway=footway highway=cycleway [0x123 resolution 20] you could now define in the overlays file 0x123: 0x2a, 0x0c and both 0x2a and 0x0c were included in the map at the same place. So if your footway looks like 0x0x0x (with 0 being transparent in typfile, and x being a color) and cycleway y0y0y0 (with y being another color), the result would be both footway and cycleway rendered as yxyxyx. routes... ups sorry should have said relations. Anything written to the relations file is not enacted anymore. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Sea Polygons and java 1.6
Hi The sea polygon patch uses a feature from java 1.6 (NavigableSet), whereas mkgmap is currently released for java 1.5. Perhaps there is a different way to do it that avoids the use, but it could be time to consider going to 1.6. Now I don't personally mind going to 1.6 and in fact I announced that this would 'happen soon' over a year ago. The only problem is people with Macs. As I have experienced with splitter (which always has required 1.6) there were quite a few queries to the mailing list and to my own email address from people not being able to run it. As there are many more downloads of mkgmap than splitter, I expect that there would be far more queries generated for mkgmap. Now as far as I know, it is no longer a problem getting 1.6 for all Macs, so I don't think anyone will be unable to run it, it is just a case of knowing what to download from where for which Mac 32/64 bit etc. So if we were to start requiring 1.6 I would like to prepare by adding a specific error message to mkgmap stating the version requirements, rather than just a stack trace that you would currently see, and to get a description of how to obtain 1.6 for the different Macs that can be placed on the wiki and web site etc. What do you think? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sea Polygons and java 1.6
On 08/22/2009 12:48 PM, Chris Miller wrote: I guess the problem is if you just compile with 1.6 and run on 1.5, the VM fails pretty quickly with a UnsupportedClassVersionError. Perhaps if you setproperty name=ant.build.javac.target value=1.5/ and checking immediately on startup to see if eg NavigableSet exists you'll be able to do what you want? Might also have to avoid 1.6 language features like @Override on interface implementations I suppose. Heh, yes what I wrote was kind of daft on the face of it, but the mkgmap distributions have always been compiled with 1.6 and target=1.5 from the very beginning, so that was exactly what I was thinking of doing. I'm quite happy to see a move to 1.6, but as you say being able to give a clear warning when running on 1.5 is probably essential to reduce the amount of support required. Agreed, so I am especially looking for Mac users to give advice and/or offer to help. In particular SoyLatte is often suggested, but this requires that you be a research licensee. The openJDK release from the same source has recently appeared and is GPL of course and so has no such restriction, but it is marked beta and although I would be surprised if there were any problem with a command line app it would be good to have it confirmed. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] options: description
Hi But I do understand what you are saying. Does anyone else have an opinion about this? Perhaps it belongs in the splitter doc then? Or the splitter could leave out (or comment out) the description lines by default, unless the --description option is given. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ant test supposed to work?
Hi On 25/08/09 23:18, Simon Josefsson wrote: In building other java applications, I'm used to checking that the build is sane by invoking 'ant test'. This fails for me with mkgmap. Is this a known problem, or something I can fix? You need to have junit in you classpath (or edit build.xml or external.properties appropriately). Version 4.5 or later is needed. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] sea polygons
Hi On 25/08/09 22:46, Christian Gawron wrote: This version of the patch fixes a bug in the previous version which caused tiles with no shoreline to be flooded. I've separated out the sea generation from the multipolygon patches and applied them to the multipolygon branch. It would be great if further patches could be relative to this branch to make it easier to see what is being changed by each patch. I have tried the resulting branch out over the whole of the UK and I get very good results. So OK there is one slight problem: http://www.mkgmap.org.uk/tmp/sea.png which looks rather neat :) But this is exactly reversed even zooming in close to islands that cross the tile boundary. But apart from one tile with the sea exactly reversed there are no other problems that I can see, and this is true when zoomed in or out. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] sea polygons
Hi Christian Can you send me the tile causing the problem or provide me a download link? http://www.mkgmap.org.uk/tmp/63240014.osm.gz It also takes 30min to compile. There is a lot of coastline there of course. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ant test supposed to work?
Hi Actually the problem was the org.hamcrest package. If anyone else runs into the same, I solved it by installing the libhamcrest-java debian package and then fixing up the installation like this: That is strange, those classes are in my junit-4.5.jar and I thought that it was directly downloaded as that is what I always do - I know that they are not in the source jar though. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Defining style-file using template.args - bug?
Hi style-file: ../mkgmap/resources/styles/mystyle mkgmap silently fails and applies the default style. Why does it bork on the ? How would it cope if you had Windows-like spaces in your path to the style file? It would *really* help if someone could add a quick patch to make sure mkgmap fails elegantly when it can't find the style file. The same problem does not occur if you invoke mkgmap with the --style-file=../mkgmap/resources/styles/mystyle option - presumably the command line interpreter handles the properly here? I agree that it should be an error if it cannot find the style, so I shall do that. As for the quotes, there is no need for quotes even if the filename has spaces in it. The only exception would be if the filename started or ended with a space. When the quotes are used in the shell, mkgmap never sees the quotes. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --tdbfile option
On 27/08/09 17:50, Robert Joop wrote: steve, the resources/help/en/options file states that the --tdbfile makes mkgmap write a .tdb file. but i always got a .tdb file, even though i never used this option. is this option only necessary when one merges .img files, and superfluous when processing .osm files? You always get one if there is more than one file (of whatever kind) being processed. I should just make it always produce the file and drop the option. There used to be a slight justification for this behaviour because in qlandkarte you could load a single .img all by itself without a .tdb or overview map, but now in qlandkartegt you always need one and the same is true of mapsource. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improving mkgmap's Unicode transliteration
Hi But really what I'm more interesting in is where mkgmap's transliteration database comes from. Knowing that will help with further contributions. There's a lot more that can be done than just improving row03.trans. That was just a sample improvement that I needed at that time. The templates are generated and the values were filled in by hand. Nothing sophisticated. Your post did lead to me to find a lot of useful tools that I had previously not been aware of and it would be great if you have ideas to improve it. As I understand it though, you really need to know the language and not just the character set in many cases. There has already been a posting saying that the Cyrillic transliteration should be different for non-Russian languages. So perhaps a somewhat different approach is needed. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap rules tiny break
Hi On 30/08/09 16:12, Felix Hartmann wrote: Just as a note for people so you don't wonder why something does not work: Rules of the follwing type * ( !=* | !=* ) will not work. and instead allways be enacted. So for example both of the follwing rules They do work, its just that the second clause of your rules can never be false, perhaps you should use 'and' instead of 'or'. match even though neither route=mtb nor route=bicycle is set: tunnel=yes ( route!=mtb | route!=bicycle ) [0x* resolution *] will show up even on mtb and bicycle routes. tunnel=yes route!=mtb route!= bicycle That would not show up on bicycle or mtb routes. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap rules tiny break
Hi oh so my logic was wrong. I would have thought that the above would not show in case both mtb AND bicycle route is set, and not OR. So how would I do that, a rule that needs all three to be true like this: ( tunnel=yes route!=mtb route!= bicycle ) [] ? Yes, that would be true for tunnel=yes and route=abc, but not when route=mtb or route=bicycle, if that is what you wanted to do. The parentheses are not needed. tunnel = yes route!=mtb route!=bicycle is the same as: tunnel = yes !(route = mtb | route = bicycle) which might be a clearer way to write it. This is supposed to be supported but was never completely implemented. I have a fix for that which I will commit in the next few minutes. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] list-styles
Hi On 31/08/09 14:51, frmas wrote: The following styles are available: arvernes 1.0: Style for OSM Maps contours 1.0: Style for OSM Maps default1.0: Style for OSM Maps noname 1.0: Style for OSM Maps perso 1.0: Style for OSM Maps test 1.0: Style for OSM Maps It seems it takes the summary line of the first style info file and apply it for all of them. Thanks for reporting this. I believe I have fixed this now. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion
Hi
As an aside, I always planned to have lists of values which might
be useful in this case. Eg. the following
#set mkgmap_surface values to either paved or unpaved
highway=* surface=asphalt {set mkgmap_surface=paved ...
highway=* surface=cobblestone {set mkgmap_surface=paved ...
highway=* surface=concrete {set mkgmap_surface=paved ...
could be represented by
highway=* surface=(asphalt, cobblestone, concrete, ...) {set
mkgmap_surface=paved
(or with the keyword 'in' instead of = perhaps)
does that sound useful?
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter version, big memory savings
Hi Chris Where to from here? As some of you may have guessed, this new splitter is Here are a few ideas based on things that we discovered with earlier versions of the splitter. * Avoid pathalogical behaviour at the poles by limiting latitude to +- 85. * Split tiles that are larger than a given absolute size, as even an empty file that is big enough will fail. Not sure what that size is, but 63240001 is probably over it. * There may also be a problem at 180 degrees longitude, caused by the overlap. It might work as long as nothing in the chain normalises, for example, 181 to -179. * Trim off areas that are completly empty, this might help with tiles that are mostly ocean with little bits of land around the edges. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter version, big memory savings
On 03/09/09 14:49, Chris Miller wrote: L And are (large) polygons that span many tiles fully supported? The splitter has been able to handle relations that span an unlimited number of tiles since r49, and ways that span many tiles since r60 or so. As far I'm not sure if this what Lambertus was thinking of but what about polygons that completely encircle a tile, or are so big that they cut across a tile in such a way that joining up the nodes in the overlap area cuts across the tile. I don't think those things can work. Probably doesn't happen for real though. Certainly no one has reported a case where that appeared to happen. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile names in IMG files
Hi On 04/09/09 10:16, Steve Hosgood wrote: Ihex number.GMP. Does anyone know how thehex number is derived please? I guess that it is a bit-interleave of the latitude and longitude of some reference-point in the tile, but it could be a byte-interleave, or a nybble-interleave, or the interleave is done with the number expressed in decimal or whatever. I don't think there is any big significance to the names, they can be fairly arbitrary strings. I guess mkgmap must generate tiles too, so this info is likely well-known to those involved in the code. We just use digit only names and the number is assigned by the mapmaker, or the tool they use to split the map. ..Steve BTW: I gather that is possible for subtile files to be given decimal-based filenames too. How does that work? Is there any difference in the actual files depending on the naming system used? Yes that is what mkgmap does. I don't think it makes any difference to anything else. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile names in IMG files
Hi On 04/09/09 16:26, Steve Hosgood wrote: I don't think there is any big significance to the names, they can be fairly arbitrary strings. Ah - not so! The .MDR file (not yet created by mkgmap) stores the names of subtile-files as 32-bit integers and expects the subtile files themselves to have names of the 'printf' format I%07lX.GMP. See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/MDR_Subfile_Format#MDR1_Subtile_List Well I don't agree. If you go to http://mapcenter2.cgpsmapper.com/ and download any of the freely available maps from there, you will see many (probably all of them) that have names that are 8 digits. It appears that all of the ones that have an installer have a mdr file. A map has a name and a number. We always make the name to be the string representation of the number, as I believe does cgpsmapper. It has never caused a problem before. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Nuvi routing performance
Hi Mark On 05/09/09 11:44, Mark Burton wrote: Playing with my shiny new Nuvi 255, I notice that it can route across an OSM map of the UK pretty well. It can find long routes reasonably quickly. In comparison, mapsource 6.13.6 often fails to determine a route at all and when it does it is rather slow about it. Previously someone claimed that on mapsource you needed a routable basemap to get good inter-tile routing, but that on a GPS device you don't. As the basemap is not sent to the device that makes sense. On the other hand the device may already have a routable base map and so perhaps it uses that if it has one and is the source of the observation. I know that on my Legend Cx which does not have a UK base map I do not get very good routing across tiles. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Styles and Typs
On 05/09/09 12:42, MarkS wrote: Are we looking to expand the number of styles included in mkgmap itself Yes absolutely I would like to have a number of different styles in mkgmap itself. I also don't mind hosting any number of alternative styles. I've created an area in subversion which can be written to by anyone (untested). You can access it at: https://svn.mkgmap.org.uk/svn/mkgmap/styles Anyone that wants to can add a style there. Secondly would it be possible to add TYP files into the style and then get mkgmap to write the TYP file to the output folder and include it in Yes it is possible and will happen. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style file not working
Hi
On 06/09/09 17:24, MarkS wrote:
Does anybody know why the following lines style file doesn't work for me:
maxspeed 78 maxspeed 82 {set mcssl=50}
highway=* mcssl=50 [0x03 resolution 22]
The first term in a rule has to have an equals sign (or the rule
can be rearranged so that is the case).
So the following should work:
highway=* maxspeed 78 maxspeed 82 {set mcssl=50}
Sorry about the error message, it is clearly useless and I will change it.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style File Problem
On 09/09/09 11:27, MarkS wrote:
Felix Hartmann wrote:
Mapsource only uses even resolution. Only gps uses uneven. So as you did
not set 20, that might be the reason to go straight up to 22. Try with
even resolution only.
I've changed the second line to
highway=primary mcssl=40 [0x04 resolution 20]
but it doesn't resolve the problem. I still get two idential roads
The problem is definitely in the generated img and not how mapsource
displays it. I would expect that both roads would be at resolution 22
which is probably not what you wanted but that is due to the usual
issue of the action rules being run in an indeterminate order.
If you need to work around the problem while I look at it try this:
(highway=* | highway=primary) maxspeed=40mph {set mcssl=40}
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style File Problem
Hi The problem lines were part of a much longer style file. Originally the file followed your work around, but this creates long style files because speed limits are defined in one of 5 ways on OSM data. I appreciate that you cut down the file to make a good example and that for the whole thing it may not be as easy. I can work around to get what I want but I guess at some point we need to find out why these particular combinations gets odd results. At first I thought there was something different going on, but it turns out that it is just the usual problem that the actions rules are not run in a well defined order. As such it will be fixed when the changes to guarantee the ordering are done, which should be fairly soon. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Merge from the multipolygon branch.
Hi Mark Why zap the final? It was there for a reason. And what would that reason be? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Moving to Java 1.6
Hi As there wasn't any voices against the change, I am now going announce that mkgmap will now require java 1.6. Just in time really as there is just over a month before 1.5 is end-of-life'd by Sun ;) During a transitional period I will compile it with target 1.5 and detect if 1.6 is not being used print a hopefully useful error messages instead of a cryptic stack trace. After a while I plan to drop that code and just compile for 1.6. If you see anything on the wiki or elsewhere that refers to java 1.5 feel free to change it. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1198: Merge in the sea polygon patch from the multipolygon branch.
Hi Mark On 17/09/09 11:22, Mark Burton wrote: 2009/09/17 10:51:34 WARNING (Osm5XmlHandler): Non-closed coastline segment does not hit bounding box: 309959855 (59.12089/-5.81827) 309959797 (59.12314/-5.81254) http://www.openstreetmap.org/?lat=59.12089lon=-5.81827zoom=17 The mkgmap never finishes, at that point it just hangs gobbling 100% CPU so I guess it's stuck in some loop. Perhaps the message is related? On my uk extract, the final tile took an excessively long time to complete, but it did eventually do so, although as reported before it was inside-out, ie all the land was sea. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search problem due to required State value
Hi On 19/09/09 12:43, Johann Gail wrote: We have some basic knowledge of the format in the wiki. Has anyone tried to generate a mdr with the known sections and see what happens on mapsource or a gps unit. Not as far as I know. But why don't we just start. I shall kick things off by creating the main files required. As there are a lot of different variations in the format, we should concentrate on one of the smallest known variations. It looks like you can create a file with only the sections: 1, 4, 5, 6, 7, 11, 15. I shall start off with a header size of 286. MDR 1: A reverse index from maps to the other sections. MDR 4: poi types, partially known MDR 5: Cities MDR 6: unknown, wiki claims it is a list of cities but I don't believe that MDR 7: Street names, optional as may be no streets MDR 11: POI's MDR 15: Strings MDR 1 points to a subsidiary header for each map, there are at least 8 subsections in this header, some of which I partially understand and I expect that all of them lead back into the other sections. It might also be useful to try for the on-device format as that is a smaller subset. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search problem due to required State value
On 21/09/09 17:03, Steve Hosgood wrote: MDR 1: A reverse index from maps to the other sections. MDR 4: poi types, partially known MDR 5: Cities MDR 6: unknown, wiki claims it is a list of cities but I don't believe that I wrote that bit of the wiki, and for me at least it's true. This is deduced from an NT map, with a record-length of 3 bytes. I wrote a Yea, the big problem is that there is not just one format, I've no idea about NT, but there are multiple different header sizes and record sizes possible. Also there is a big difference between the full format as it comes with a map for mapsource, and the format when it transformed and put inside the gmapsupp. In fact I've just looked at the on device version of MDR 6 and the records are three bytes and there does appear to be a map index as the first byte, which is entirely different from the mapsource version. Its all useful, but you need to be clear on what exactly you are documenting. I'm planning to do the full version first, but if that doesn't pan out I may try for the on device version. Clearly we want both eventually. NT maps (with MDR1 using a record-length of 4 bytes) seems to be listing the GMP subtile files. I hear that there are 8 bytes variants - don't know about them. OK 4 byte records in MDR1 is the on device format, so I guess that confirms that you are working from a map on a GPS device? It sounds like a good idea at least to try generating MDR files though - go for it! So far I have a test mdr with a country, region and a city, but no luck getting it to work so far though. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search problem due to required State value
On 21/09/09 19:12, Felix Hartmann wrote: Why do you try to go for NT format? Address search worked very well with non NT maps too. cpgsmapper also makes classic non NT maps. In case it wasn't clear I am going for the classic format, like everything else in mkgmap, and not for the NT format. I've no idea what the mdr looks like in NT and of course if it is vastly different then it will not help the current effort. It is probably easier to start looking at non NT maps with address search. At least non NT maps are not needed to be transformed when sent to GPS. The maps aren't, but the MDR is. Many parts of it are left out. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap, sendmap and family-name oddities
Hi On 22/09/09 09:28, Charlie Ferrero wrote: 2a: I use sendmap to upload the file to my GPS 2b: I copy the file manually to the memory card Result of 2a: In the GPS, map tiles are listed as [description], [family-name], [date of creation] Result of 2b: In the GPS, map tiles are listed as [description], Area 6324999X, [date of creation] That is interesting. The only place that 'Area ...' occurs is in the MPS file in the gmapsupp.img. Its controlled by the --area-name flag, but that is the only place that it is used. At some point I will attempt to match up the usage of description, series-name, family-name and area-name with the different names used in Polish format files. Has anyone done this already and have opinions on what should be done? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1215: Added sections for POI and POI type (10 and 11)
On 22/09/09 00:07, maning sambale wrote: what switch do I add to enable mdr creation? There is nothing even remotely usable yet. I am just writing a program by hand that will only work with a single map. And at the moment not even that. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap, sendmap and family-name oddities
Hi mb.setAreaName(areaName != null ? areaName : Area + info.getMapname()); in GmapsuppBuilder sets the area name when none is given. To me the behavior reported by Charlie Ferrero is more or less what I was expecting. There is no reason to expect a tool like sendmap would have the same defaults as mkgmap. My GPS has no external memory so I can not test myself. Perhaps Charlie Ferrero needs to try is setting the --area-name to what he wants his map named? What you say is absolutely correct technically. The only question was since area-name is not contained in anything that is given to MapSource, when mapsource sends a map to the device it can't use it. However, I just remembered that when you are uploading maps with mapsource you get a chance to type in your own name for the map set. That name defaults to family-name. If it can be confirmed that this is the meaning of area-name then I will leave it in and document it as such, but probably let it default to family-name instead of 'Area ...'. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MDR success and a couple of questions
Hi I've managed to construct a working MDR file with all of 2 POIs in it. This is with sections 1 (with empty subsections), 4, 9, 10, 11, 15. That appears to be the minimum number of sections to get anything to work. Interestingly, MDR 15 doesn't appear to be used much. It supplies auto-completion results when typing in the search boxes, but the actual search results show the actual labels of the points. So 4 and 9 are required but I don't completely understand them, so does anyone know or speculate what the second byte in MDR 4 is? The wiki says 'kind of index', suggesting that it tells you which sections use that POI type. If that is what is meant then what is the mapping? Secondly any ideas on MDR 9? The first record always appears to be 01 01 00 00, and that is enough to make searching work in my simple example, but beyond that I have no idea. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR success and a couple of questions
On 22/09/09 16:31, Steve Hosgood wrote: On my NT map, MDR9 only contains a single 4-byte element, containing just 01 01 00 00 just as you describe. So evidently that's an accepted OK Thanks, that is encouraging. I shall just plough on, hoping that is all we need in 9 for now. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug report : closed contour lines are opened
On 11/09/09 20:00, Johann Gail wrote: I know that there some thime ago there was some error in the douglas peucker code, which drops the first or last segment of a polygon. A solution was discussed, but I'm not sure, if this solution has found its way into the trunk. I have the patch DP2.patch, which I see you did say should be committed from the 25 Aug. It still applies OK and there are no noticeable problems so I shall commit it. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1215: Added sections for POI and POI type (10 and 11)
On 23/09/09 19:25, Johann Gail wrote: So where I have to start, if I want to take part at your improvements and test at my equipment? How is this program called? The program I was using was the class MdrTestCreator. However I am just about to branch onto an mdr branch as further progress requires modifying existing classes. All the code is in the uk.me.parabola.imgfmt.app.mdr package so far. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR success and a couple of questions
On 23/09/09 21:19, Johann Gail wrote: While looking at the mdr files a question arose. What has the filename of the mdr to be? I.e. what has to be in front of the *.mdr? Does the number has a meaning? Not as far as I know. I believe it is just like the overview map and can have any ascii characters in it. I called mine test and that was OK. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strict ordering of action in a style rule file.
Hi On 23/09/09 18:54, Torsten Leistikow wrote: today I had the time to try out the style-brunch: With a cleaned-up version of my style the result was ok. Compared to the trunk version all known problem cases came out allright. OK that is good thanks for trying that out. But I am in the same situation as Felix: My styles rely heavily on the creation of multiple elements per stop/continue scheme. So I can not test the new ordering with my full style rules. Right, I can add a continue function. Would it be possible for you or Felix to send me a complete file with those rule so I can see how they are really used in practice? Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] LBL subfile details
On 23/09/09 15:52, Anton Todorov wrote: Here are some findings that i can not manage to code in java... In mkgmap the text between the header and the first lbl section is hardcoded to the string 'mkgmap'. This section is defined at the end original files the text is 'American'. In the source it is commented as // Sort descriptor ??? I could speculate that this is kind of dictionary name(like 'American English'). Another finding is So that would explain what Sort Descriptor meant. All cgpsmapper created files just have a string like 'map created with cgpsmapper' which is why mkgmap ones just have the hardwired string in them. (when the texts are coded in 6bits) that the first byte of LBL1 is 0xFF(in Metro Guide) which is decoded as 0x3F == 'End Marker'. In mkgmap it is 0x00 that i think is not correct. All elements that have no name have lbl1 pointer to this end marker so it should be 0xFF. [...] OK, I believe this. But, have you noticed any problems caused by it though? [...] If there are points for the cities and LBL1,2,3,4 are filled in the overview map img, menu Find-Find Places has working City tab in MapSource. Maybe overview img participate in the indexing in some Ah ha, that is interesting. I did recently notice that the trip and waypoint map that came with my GPS had city search even though it does not have the global index file. The work I've started on the global index will also allow us to create a better overview map too so we could do this then. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search problem due to required State value
On 24/09/09 12:32, maning sambale wrote: Excellent progress! I mentioned before I don't get much of this hexa engineering. But I have several mdr files for anyone to look into. I anyone interested? Where do I dump them? Thanks, but have plenty. There are any number of free maps at mapcenter2[1]. I have started the new branch and will shortly check in code to generate (mostly) empty files directly from mkgmap. ..Steve [1] http://mapcenter2.cgpsmapper.com/ (down as I write this;) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1234: Add the 'continue' attribute to the type.
On 27/09/09 10:58, svn commit wrote: Version 1234 was commited by steve on 2009-09-27 10:58:41 +0100 (Sun, 27 Sep 2009) BRANCH: style Add the 'continue' attribute to the type. Please don't try to use this just yet, as it will hang for anything more than the simplest of cases. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1235: Fix hang on continue action.
On 27/09/09 21:28, Felix Hartmann wrote: Thanks for your work, sadly though for me at the moment the style branch is useless because continue on the strictly ordered style rules has no effect. (I need to have the rules running not only in order, but also if continue given, several rules on the same object. (actually I don't even Thanks for testing it. I was trying out your style file and it didn't appear to be working for me either but I couldn't be sure, since I don't really know what it should be like. Obviously it is a bug if multiple lines are not being created. Plus, it runs about 10 times slower than the trunk branch (plus continue I've not really looked at the performance yet, but there is no reason why it should be any slower, so I'm sure that is fixable. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Mkgmap appears to hang on some split files
Hi Lambertus On 28/09/09 08:36, Lambertus wrote: While trying to get a new world map update out the door I noticed that Mkgmap sometimes hangs on an OSM data file produced with Splitter. When this happens the CPU is at 100% constantly for hours (e.g. all night) until I kill the process. The problem occurs in r1222 and also r1228. I ran the command line you gave with 1222 and 1228 on both the files and it completed in about a minute. So no hang for me, and I'm going to have to ask a few questions to have any idea. Is there any version where it works without hanging for you? What OS was it running on? What is the LANG variable set to (if running on Linux)? Could you send a stack dump when it is stuck, since it completes after 1 minute for me, probably waiting five minutes is more than enough to know that it is stuck. You can get a stack trace using typing ctrl-\ or using kill -QUIT on linux and on windows ctrl-break is supposed to work but I wouldn't know. Another way that works the same everywhere is to use jstack. Use jps to get the process id of the running processes and call jstack with that id. jstack and jps come with JDK download of java from sun and probably other places too. Thanks ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Mkgmap appears to hang on some split files
On 28/09/09 15:09, Lambertus wrote: The error files were produced using kill -4pid. Kill -1 till -3 had no effect on the process. Just switching to using Sun Java is probably That would explain it then :) But -3 should have caused java to write out the stack traces onto standard output. If you would have seen that but didn't that would also lend support to the idea that java itself was hung. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1244: Fix sorting of records in MDR 4.
On 29/09/09 18:19, Anton Todorov wrote: The socond byte look like flags 0x00 if the point has record in mdr5,mdr25,mdr27? 0x01 no references in other subfiles 0x03 - the point is city I like your idea that it is a set of flags indicating which sections it is in, but I don't think it can be true. These are not on individual points but on whole classes of points. Also it is always true that eg. 0xb is a city, so there is no need for anything else to say that. Since mdr5 is also for cities, 00 overlaps with 03. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR success and a couple of questions
Hi Alex The unknown byte is sequential as you see above. From MDR4 where the type changes(just type, no the subtype) it coresponds to a record here. So you have a type from here you find where point with that type start in MDR10. At first I didn't see how this could work with my example files, but I now think you are correct with one small difference in that type 0x28 is out of place: first byte: type 1: all city types and perhaps all indexed points 2: 2a 3: 2b ... etc 7: 2f 8: 30 9: 28 So group 9 is out of order. Also what about points that have a type 0x30? File that have such points do not any entries in mdr 4 for them. Perhaps you just can't search for them? MDR10 - POIs indexed by type 1 bytes - subtype Ha - I realised today it was subtype and not type, but I see you said it first. 2/3 bytes - POI index in MDR11 - index have 0x8000 or 0x80 flag- if the point is indexed or not I think this flag is actually to say if the name is new or not. If the flag is not set, then the name of the POI is the same as the name of the previous poi. Thanks I think I will be able to write mdr9 tommorow and hopefully everything will stop being a city! Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1246: Impelent mdr 4 and 9 as best as we know.
On 30/09/09 11:23, Felix Hartmann wrote: I think this is style dependant? I get 50% rubbish right now - (as compared to what I find via nearest places) in all categories. Yes I do see quite a lot of things that shouldn't be there, up to 50% I would agree. If you get it to show the same as nearest places it would be great, otherwise (but this would be a good idea in any case) it would be great if one could exclude POI via points file in the style-file e.b. by having a line like this: highway=traffic_lights [0x* resolution 24 -noindex] There are many POI that are nice to have in a map, but not needed to be searched for (e.g. traffic_lights, park benches, railway crossings, trees, diverse obstacles like bump_gate, kissing_gate,..., water_tower, energy plant, cliff, wayside shrine, ... Well as far as I can tell most or all of those things can't be in the index anyway, and also only things that have names are included. So once it is fully working I think it will be just fine. But lets wait until then and see. Really great that it is more or less working however! (well city, state/province, country still not usable - city would be great to have off course) Yes I think we know enough to add these, so that should happen fairly quickly, barring unforeseen problems. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1246: Impelent mdr 4 and 9 as best as we know.
Hi On 30/09/09 12:25, Felix Hartmann wrote: Hmm, what is if you add names via style-file? Will they then show up (this could be of good use, and also of bad use...) They would show up, I would think. Currently I get many showing up WITHOUT name however too: That is part of the bug, those things are not really in the index. Try searching for a category and a name beginning with 'a'. You can get all kinds of thing that do not have names beginning with an 'a', most of them will be the rubbish that shouldn't be there. Once it is working properly empty names shouldn't happen. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1235: Fix hang on continue action.
Hi
highway=crossing crossing=zebra_crossing {set
highway=deleted_crossing} [0x4004 resolution 24 continue]
highway=crossing [0x610f resolution 24 continue]
two elements are created on the map (0x610f and 0x4004).
My idea of the continue-statement would mean, that only the first
element should be created, because afterwards the second rule isn't
matching anymore.
Yes that is what should happen, so it is a bug.
Previously changing a tag that was later matched did not work reliably,
but I added code to make it work as part of strict ordering. Or so I
thought!
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
