Re: [mkgmap-dev] [PATCH v1] Display MDR6
On 18/01/11 17:28, WanMil wrote: Displays section MDR6 of the MDR. Steve, can you commit that? I have no commit rights on the display svn. It is committed. You should have commit to display now. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] elevation contours, wrong values
On Tue, 2011-01-18 at 21:46 +0100, Henning Scholland wrote: Hi, in the resulting osm-file are all values correct. Eg. the elevationline for 20m is tagged with ele=20. Also this line is displayed there elevation is 20m. But this line is named as 6m. srtm2osm-call should be correct. It creates metric values unless you set -foot, what I haven't done. MapSource use also metric system. Henning Assuming there is no bug in mkgmap, you should check your style file. GARMIN store elevation heights internally in feet, so the meters must be converted to feet by mkgmap, following settings in the style file. Form your post it would appear that this is not happening. I have only used contours with polish format input. With polish format you need to add elevation=M in the header portion of the mp file to tell mkgmap you are using meters. From what I can see this is handled by the style file for OSM input. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug: Restaurant with internet_access=no makes 2 POIs
On Wed, Jan 19, 2011 at 10:49:37AM +0700, Peter Hendricks wrote: Sorry Marko, you lost me there. I don't use styles for the quick and dirty maps I make for my mapping purposes. For navigation I use Lambertus' maps (and as far as I know he doesn't use any custom styles, either). The patch that I posted is for the default mkgmap style, which you and Lambertus ought to be using. I maintain that style (have not updated it for a while, though). Don't worry, I will create a test map in JOSM to reproduce this bug and to see if my patch fixes it (and does not make POIs with internet_access=wlan disappear, for example). Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Amenity=shelter
On Wed, Jan 19, 2011 at 10:32:04AM +0700, Peter Hendricks wrote: 4 posts in the ground with some kind of overhanging roof. People will seek shelter under the roof from either sun or rain. These are found all over Thailand on road sides. If it rains you can often even get your bike in there, if there aren't too many people. There are no bus stops in the country side, but people may wait there for public transport. You can't call it a building, as it doesn't have walls. Whatever you call it, it should not show in the map as a camp ground, as even alpine shelters have nothing to do with that. OK, what about this? Replace amenity=shelter with tourism=lean_to in the default style. Then, no amenity=shelter would show up in the map. If you can suggest a sensible Garmin symbol code for amenity=shelter, we can add that as well. Service station is probably not a good description, as that implies a place run by a petrol company. For the POI I would suggest Exit Services if the area doesn't have a name, but others may have better ideas. What about just Services? That would work a little better in other languages than English languages, because the OSM tag is highway=services. Services can be understandable in more languages than exit, and the exit does not seem to add much value in English either. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
On 11/01/11 12:21, Minko wrote: Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes. OK, the option shouldn't cause a crash, but since it was reported as being a possible problem it was worth trying. Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois. No I don't expect it will make any difference there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi Thanks for testing. On my unit (Nuvi200W) the problem remains the same (as reported before by other people): Address search is not available, as the unit requests the state/province i.s.o. country, and refuse any input, or rather does not Yes I am not expecting any change here yet. I have an idea of what to do next, but will not be able to code it for a couple of days. The only other difference I've noticed is that I can not find streets in POI search as I switched road-name-pois off to test address search. Please never get rid of this option, until all units have proper address search. It is a life saver -- a map where you cannot find a street is useless. Thats true, and it is not going to be removed. For testing however, it is an unnessary complication when combined with the index. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
I notice that a number of people are using: the --make-poi-index option which is marked as 'not yet useful' in the help. Has anyone checked if makes any difference and that it is not actually harmful? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi My tiles have one speciality: They are quite small. I have splitted with max-nodes=10. I suspect that mdr8/12 should not be included if there is only one entry as it is in your case. Once I get the chance I will try fixing that, but you might want to see if it helps removing the sections first. I have not noticed any improvement from those sections anyway. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
On 19.01.2011 13:08, Steve Ratcliffe wrote: On 11/01/11 12:21, Minko wrote: Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes. OK, the option shouldn't cause a crash, but since it was reported as being a possible problem it was worth trying. Never noticed a crash in Mapsource due to it, only on GPS. I would exclude it for less possible troubles nevertheless (once address search works correctly, this option is obsolete anyhow). Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois. No I don't expect it will make any difference there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi I had some looks at the code, especially on MDRSection7, which is important for street search. And, yes, there are some more fields decoded. But most of the comments are in polish, so it's very hard (at least for me) to unterstand what those fields are used for and where to get the required data. There are other possible fields but they are not necessarily essential as mapsource adds some of these fields when it downloads to a device, so they do not need to be present in the index to begin with. As far as I understand it, one of these fields is a flag to say that there is more than one word in the name of the street (or perhaps a count). Another field is used for an alternative kind of index where every word in the street name is indexed separately. So if you had a name: Yellow Grass Lane it would be sorted under 'Y' as normal, but also under 'G'. The entry that was under 'G' would have this field set to the position of the character 'G' in the name - so 8 in this case (or 7 if it starts at 0 - whatever). While this would be useful, we need to get the basic index working first. It would be good to know exactly what is required to get things working on the device, since the index has very many possible sections and we don't have enough people working on it to implement everything. My next guess would be mdr 20, 21, 22 as these are referred to in the reverse index which is used by mapsource to determine what is downloaded to the device. They are lists of pointers into the street names ordered in particular ways (city, region etc) and so very relevant to the problem areas. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi My tiles have one speciality: They are quite small. I have splitted with max-nodes=10. I suspect that mdr8/12 should not be included if there is only one entry as it is in your case. Once I get the chance I will try fixing that, but you might want to see if it helps removing the sections first. I have removed them from the MdrFile class without any improvement. MapSource still crashes when opening the search dialog. WanMil I have not noticed any improvement from those sections anyway. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
I notice that a number of people are using: the --make-poi-index option which is marked as 'not yet useful' in the help. Has anyone checked if makes any difference and that it is not actually harmful? ..Steve I have removed the make-poi-index option but it does not seem to make any difference. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Index: MDR12 breaking POI search
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9',' ','-') are replaced by 'Z'. As far as I
understood the character encoding might be a problem. So replacing all
problematic characters might help. (see attached patch)
2nd: I splitted Germany with the default splitter settings so that I get
big enough tiles.
3rd: I removed MDR8 and MDR12 from the MDRFile class.
4th: I compiled a map using 2 tiles from my Germany split.
The result was interesting:
* POI search works
* All region search fields are disabled
* I don't see any more exceptions or crashes in MapSource
* Street search still has the problem with the message Selected street
is not allowed in this map product (translated from german...)
* Most of the country information is set to ABC. I don't know if that
has something to do with removing the --make-poi-index option?
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java (revision 1787)
+++ src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java (working copy)
@@ -16,6 +16,8 @@
*/
package uk.me.parabola.mkgmap.reader.osm.xml;
+import java.nio.charset.Charset;
+
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.reader.osm.Element;
@@ -34,12 +36,12 @@
/**
* Reads and parses the OSM XML format.
- *
+ *
* Creates the nodes/ways and relations that are read from the file and passes
* them to the OsmCollector.
- *
+ *
* It should not examine tags, or do anything else.
- *
+ *
* @author Steve Ratcliffe
*/
public class Osm5XmlHandler extends OsmHandler {
@@ -67,35 +69,40 @@
public Osm5XmlHandler(EnhancedProperties props) {
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
- reportUndefinedNodes = props.getProperty(report-undefined-nodes, false);
+ reportUndefinedNodes = props.getProperty(report-undefined-nodes,
+false);
}
/**
* The XML handler callbacks.
- *
- * Need an inner class here so that the top class can inherit from OsmHandler.
+ *
+ * Need an inner class here so that the top class can inherit from
+ * OsmHandler.
*/
public class SaxHandler extends DefaultHandler {
/**
* Receive notification of the start of an element.
- *
- * @param uri The Namespace URI, or the empty string if the
- * element has no Namespace URI or if Namespace
- * processing is not being performed.
- * @param localName The local name (without prefix), or the
- * empty string if Namespace processing is not being
- * performed.
- * @param qName The qualified name (with prefix), or the
- * empty string if qualified names are not available.
- * @param attributes The attributes attached to the element. If
- * there are no attributes, it shall be an empty
- * Attributes object.
- * @throws SAXException Any SAX exception, possibly
- * wrapping another exception.
+ *
+ * @param uri
+ *The Namespace URI, or the empty string if the element has
+ *no Namespace URI or if Namespace processing is not being
+ *performed.
+ * @param localName
+ *The local name (without prefix), or the empty string if
+ *Namespace processing is not being performed.
+ * @param qName
+ *The qualified name (with prefix), or the empty string if
+ *qualified names are not available.
+ * @param attributes
+ *The attributes attached to the element. If there are no
+ *attributes, it shall be an empty Attributes object.
+ * @throws SAXException
+ * Any SAX exception, possibly wrapping another exception.
* @see ContentHandler#startElement
*/
- public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
+ public void startElement(String uri, String localName, String qName,
+Attributes attributes) throws SAXException {
if (mode == 0) {
if (qName.equals(node)) {
mode = MODE_NODE;
@@ -109,18 +116,19 @@
} else if (qName.equals(relation)) {
mode = MODE_RELATION;
- currentRelation = new GeneralRelation(idVal(attributes.getValue(id)));
+ currentRelation = new GeneralRelation(
+ idVal(attributes.getValue(id)));
} else if (qName.equals(bound)) {
mode =
Re: [mkgmap-dev] Index: MDR12 breaking POI search
Am 19.01.2011 20:15, schrieb WanMil:
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9',' ','-') are replaced by 'Z'. As far as I
understood the character encoding might be a problem. So replacing all
problematic characters might help. (see attached patch)
2nd: I splitted Germany with the default splitter settings so that I get
big enough tiles.
3rd: I removed MDR8 and MDR12 from the MDRFile class.
4th: I compiled a map using 2 tiles from my Germany split.
The result was interesting:
* POI search works
* All region search fields are disabled
* I don't see any more exceptions or crashes in MapSource
* Street search still has the problem with the message Selected street
is not allowed in this map product (translated from german...)
* Most of the country information is set to ABC. I don't know if that
has something to do with removing the --make-poi-index option?
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
WanMil
Compiling a map
- with the index_nospecialchars_v1.patch: Region field disabled
- without the index_nospecialchars_v1.patch: Region field enabled
I do not understand...
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Steve Ratcliffe schrieb: Hi I had some looks at the code, especially on MDRSection7, which is important for street search. And, yes, there are some more fields decoded. But most of the comments are in polish, so it's very hard (at least for me) to unterstand what those fields are used for and where to get the required data. There are other possible fields but they are not necessarily essential as mapsource adds some of these fields when it downloads to a device, so they do not need to be present in the index to begin with. Correct, I think we should get basic search working first. But my final destination would be a working search on the devices without downloading from mapsource. I would be very happy, if we get so far. As far as I understand it, one of these fields is a flag to say that there is more than one word in the name of the street (or perhaps a count). The xflag seems to be a count of some sort. The count could become greater then 256 and then it will be splitted to two bytes. Or are this the accented characters with an ascii code 256? I don't think so. Also I think this is optional and not needed for basic working. Another field is used for an alternative kind of index where every word in the street name is indexed separately. So if you had a name: Yellow Grass Lane it would be sorted under 'Y' as normal, but also under 'G'. The entry that was under 'G' would have this field set to the position of the character 'G' in the name - so 8 in this case (or 7 if it starts at 0 - whatever). While this would be useful, we need to get the basic index working first. It would be good to know exactly what is required to get things working on the device, since the index has very many possible sections and we don't have enough people working on it to implement everything. My next guess would be mdr 20, 21, 22 as these are referred to in the reverse index which is used by mapsource to determine what is downloaded to the device. They are lists of pointers into the street names ordered in particular ways (city, region etc) and so very relevant to the problem areas. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev . ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
Hi I observed the same result when I added the MDR8. Adding MDR12 returns to the old behaviour with exceptions and MapSource crashes. Thanks that was a good clue I hope. I modify the size of the section mdr11 in the routine that writes it out. As all the sections depend on each other and need to know their sizes this is too late. I have extracted out the code that changes the section size into a finish() method which is called before anything is written out. I am not in a possition to test it however, but I am sure that the previous code was wrong - the change may not go far enough. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
WanMil schrieb: Has anyone dared to look into the cpreview code? So we do at the moment. http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/mdr_creator.cpp?revision=4view=markup There seems the structure of the bits be very well decoded. More or less. Please feel free to start your own investigations and compare the mkgmap results to the format of the cpreview tool. Any hint or discussion what might be changed in the mkgmap processing is helpful!! I have tried to compile the source with linux, but had no success so far. Looks like it needs the intel compiler and some source dependencies, e.g. sqlite3 source. I have not tried hard, so maybe would need more time to become succesfull. Does anyone know which input files the cpreview tool will need? Does it import the prepared *.img files like mkgmap or does it need some other database or text files? If I would be able to generate a working index with it, I could play with it and see, which sections are really needed on the device. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to solve/debug weird problem
Hallo Johannes, while I cannot help with the actual bug, I can give you some advice to narrow it down. Once you have a minimal test case, your bug should be fixable. On Tue, Jan 18, 2011 at 09:52:13PM +0100, Johannes Formann wrote: rerun with a reduced option set (an the debug-patch still active): [apply] Executing 'java' with arguments: '-Xms256m' '-Xmx2560m' '-ea' '-jar' 'mkgmap.jar' '--max-jobs=1' '--style-file=radkarte' Does the problem disappear if you remove --style-file (i.e., use the default style)? '--overview-mapnumber=5942' '--overview-mapname=5942' '--series-name=OSM_Radkarte' '--product-id=1' '--family-id=5942' '--family-name=OSM Radkarte 18.01.2011' '--country-name=Deutschland' '--country-abbr=DE' My educated guess is that these should not matter at all (please confirm by trying to removing these). '--latin1' '--code-page=1252' '--add-pois-to-areas' '--adjust-turn-headings' '--drive-on-right' '--check-roundabouts' '--remove-short-arcs=3.3''--net''--route' '--gmapsupp''--tdbfile''--index' 'M0001736.TYP''-c''/home/osm/build/template.args' What is in template.args? Any options before the file name 59420059.osm.gz? But got an Exception again. [apply] SEVERE (MapSplitter): /home/osm/build/59420059.osm.gz: ... What if you replace these last bits '--gmapsupp''--tdbfile''--index' 'M0001736.TYP''-c''/home/osm/build/template.args' with just /home/osm/build/59420059.osm.gz That should speed up the crash, shouldn't it? Please save that problematic tile file somewhere, so that you can test patches with the exact same input. The faster the command runs, the easier you can test different options until you find the minimal options that are needed to trigger the bug. You might also want to drop definitions from your style file until the crash goes away. But I would first try to reduce the other command line options before touching the --style-file option or the style definitions. Another way of reducing would be to load the tile file in a powerful text editor and drop half the relations (or all of them if the crash persists), then drop half the ways, and so on, until the crash goes away. That would lead to a minimal test case. But I guess that Steve or WanMil can do that sort of processing if you make the file available to them. But, first try to narrow down the options and the style definition. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] How does cgpsmapper / cpreview work
Just as I don't want to post this in other threads as O.T. here seems to be the bext explications on how cpreview works (and why mkgmap maps are unsuitable for further processing to create an index using cpreview). http://pkmaps.freeforums.org/compiling-a-garmin-img-map-using-cgpsmapper-ver-95-above-t63.html As you can read, cpreview needs an idx file created by cgpsmapper (and cgpsmapper needs properly prepared maps by gpsmapedit, it does not have any intelligent function to create an address search from scratch as does mkgmap). We cannot use cpreview on osm map data for address search. The only thing I could image for testing is asking Malsingmaps authours or someone else if he could give us both a proper mp ready to be handled by cgpsmapper professional version, and the finished outcome. Maybe on could use mapcenter2 for this too ( if we had a proper mp to start with). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9',' ','-') are replaced by 'Z'. As far as I
understood the character encoding might be a problem. So replacing all
problematic characters might help. (see attached patch)
2nd: I splitted Germany with the default splitter settings so that I get
big enough tiles.
3rd: I removed MDR8 and MDR12 from the MDRFile class.
4th: I compiled a map using 2 tiles from my Germany split.
The result was interesting:
* POI search works
* All region search fields are disabled
* I don't see any more exceptions or crashes in MapSource
* Street search still has the problem with the message Selected street
is not allowed in this map product (translated from german...)
* Most of the country information is set to ABC. I don't know if that
has something to do with removing the --make-poi-index option?
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
WanMil
Compiling a map
- with the index_nospecialchars_v1.patch: Region field disabled
- without the index_nospecialchars_v1.patch: Region field enabled
I do not understand...
WanMil
As one obviously thing you will change the sorting order of some
streets. (The streets with the accented chars. ) But this should really
not be the problem...
Have you checked with the display tools that nothing other gets changed?
There should be no change in length of lists nor in other structures.
Johann
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] elevation contours, wrong values
Thanks a lot, this was the hint I needed. Works now very well. Henning Am 19.01.2011 13:28, schrieb garvanmaew: On Tue, 2011-01-18 at 21:46 +0100, Henning Scholland wrote: Hi, in the resulting osm-file are all values correct. Eg. the elevationline for 20m is tagged with ele=20. Also this line is displayed there elevation is 20m. But this line is named as 6m. srtm2osm-call should be correct. It creates metric values unless you set -foot, what I haven't done. MapSource use also metric system. Henning Assuming there is no bug in mkgmap, you should check your style file. GARMIN store elevation heights internally in feet, so the meters must be converted to feet by mkgmap, following settings in the style file. Form your post it would appear that this is not happening. I have only used contours with polish format input. With polish format you need to add elevation=M in the header portion of the mp file to tell mkgmap you are using meters. From what I can see this is handled by the style file for OSM input. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
WanMil schrieb:
Am 19.01.2011 20:15, schrieb WanMil:
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9',' ','-') are replaced by 'Z'. As far as I
understood the character encoding might be a problem. So replacing all
problematic characters might help. (see attached patch)
2nd: I splitted Germany with the default splitter settings so that I get
big enough tiles.
3rd: I removed MDR8 and MDR12 from the MDRFile class.
4th: I compiled a map using 2 tiles from my Germany split.
The result was interesting:
* POI search works
* All region search fields are disabled
* I don't see any more exceptions or crashes in MapSource
* Street search still has the problem with the message Selected street
is not allowed in this map product (translated from german...)
* Most of the country information is set to ABC. I don't know if that
has something to do with removing the --make-poi-index option?
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
WanMil
Compiling a map
- with the index_nospecialchars_v1.patch: Region field disabled
- without the index_nospecialchars_v1.patch: Region field enabled
I do not understand...
WanMil
Just found at
http://pkmaps.freeforums.org/to-enable-find-search-address-option-for-maps-in-gpsmapedit-t61.html
Note: Always use UPPER CASE for defining Country, Region, City etc
because many Garmin devices can only allow users to text in alphabets in
Upper Case.
Maybe you should modify your patch to only allow upper case letters.
Regards,
Johann
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
Hi I observed the same result when I added the MDR8. Adding MDR12 returns to the old behaviour with exceptions and MapSource crashes. Thanks that was a good clue I hope. I modify the size of the section mdr11 in the routine that writes it out. As all the sections depend on each other and need to know their sizes this is too late. I have extracted out the code that changes the section size into a finish() method which is called before anything is written out. I am not in a possition to test it however, but I am sure that the previous code was wrong - the change may not go far enough. ..Steve Thanks Steve, your code changes did not have any effect on my tests so there must be some more things to do. POI search shows exception if MDR12 is put into MDR. But we know for sure that our MDR12 creation has a problem. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
WanMil schrieb: Has anyone dared to look into the cpreview code? So we do at the moment. http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/mdr_creator.cpp?revision=4view=markup There seems the structure of the bits be very well decoded. More or less. Please feel free to start your own investigations and compare the mkgmap results to the format of the cpreview tool. Any hint or discussion what might be changed in the mkgmap processing is helpful!! I have tried to compile the source with linux, but had no success so far. Looks like it needs the intel compiler and some source dependencies, e.g. sqlite3 source. I have not tried hard, so maybe would need more time to become succesfull. Does anyone know which input files the cpreview tool will need? Does it import the prepared *.img files like mkgmap or does it need some other database or text files? If I would be able to generate a working index with it, I could play with it and see, which sections are really needed on the device. Regards, Johann Yep, so you are exactly at the same stage like I am. At the moment I am only able to do a code review of cpreview. I think Felix answered how cpreview should work so I continue in his thread. Have fun! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How does cgpsmapper / cpreview work
Just as I don't want to post this in other threads as O.T. here seems to be the bext explications on how cpreview works (and why mkgmap maps are unsuitable for further processing to create an index using cpreview). http://pkmaps.freeforums.org/compiling-a-garmin-img-map-using-cgpsmapper-ver-95-above-t63.html As you can read, cpreview needs an idx file created by cgpsmapper (and cgpsmapper needs properly prepared maps by gpsmapedit, it does not have any intelligent function to create an address search from scratch as does mkgmap). We cannot use cpreview on osm map data for address search. The only thing I could image for testing is asking Malsingmaps authours or someone else if he could give us both a proper mp ready to be handled by cgpsmapper professional version, and the finished outcome. Maybe on could use mapcenter2 for this too ( if we had a proper mp to start with). Thanks Felix, I was also wondering how the cpreview tool might be used. But your investigation answered my questions. Did someone try the free cgpsmapper 0100 version? I think it does not create the .idx file? I tried to create mp files by running osm2mp. I installed it on Ubuntu but I got several perl errors... WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
Am 19.01.2011 22:07, schrieb Johann Gail:
WanMil schrieb:
Am 19.01.2011 20:15, schrieb WanMil:
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9',' ','-') are replaced by 'Z'. As far as I
understood the character encoding might be a problem. So replacing all
problematic characters might help. (see attached patch)
2nd: I splitted Germany with the default splitter settings so that I get
big enough tiles.
3rd: I removed MDR8 and MDR12 from the MDRFile class.
4th: I compiled a map using 2 tiles from my Germany split.
The result was interesting:
* POI search works
* All region search fields are disabled
* I don't see any more exceptions or crashes in MapSource
* Street search still has the problem with the message Selected street
is not allowed in this map product (translated from german...)
* Most of the country information is set to ABC. I don't know if that
has something to do with removing the --make-poi-index option?
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
WanMil
Compiling a map
- with the index_nospecialchars_v1.patch: Region field disabled
- without the index_nospecialchars_v1.patch: Region field enabled
I do not understand...
WanMil
Just found at
http://pkmaps.freeforums.org/to-enable-find-search-address-option-for-maps-in-gpsmapedit-t61.html
Note: Always use UPPER CASE for defining Country, Region, City etc
because many Garmin devices can only allow users to text in alphabets in
Upper Case.
Maybe you should modify your patch to only allow upper case letters.
Regards,
Johann
That might be a good hint but I think Steve already does this in the MDR
creation process?!
The patch must allow lower case letters. Otherwise all highway=primary
will become highway=PRIMARY and all styles are no longer working...
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How does cgpsmapper / cpreview work
On 19.01.2011 22:36, WanMil wrote: Just as I don't want to post this in other threads as O.T. here seems to be the bext explications on how cpreview works (and why mkgmap maps are unsuitable for further processing to create an index using cpreview). http://pkmaps.freeforums.org/compiling-a-garmin-img-map-using-cgpsmapper-ver-95-above-t63.html As you can read, cpreview needs an idx file created by cgpsmapper (and cgpsmapper needs properly prepared maps by gpsmapedit, it does not have any intelligent function to create an address search from scratch as does mkgmap). We cannot use cpreview on osm map data for address search. The only thing I could image for testing is asking Malsingmaps authours or someone else if he could give us both a proper mp ready to be handled by cgpsmapper professional version, and the finished outcome. Maybe on could use mapcenter2 for this too ( if we had a proper mp to start with). Thanks Felix, I was also wondering how the cpreview tool might be used. But your investigation answered my questions. Did someone try the free cgpsmapper 0100 version? I think it does not create the .idx file? I tried to create mp files by running osm2mp. I installed it on Ubuntu but I got several perl errors... WanMil As far as I understood, only mapcenter2 is a free alternative that one can use. However http://mapcenter2.cgpsmapper.com/ is down since quite a few month. Or someone got a working link? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
WanMil schrieb: Hi I observed the same result when I added the MDR8. Adding MDR12 returns to the old behaviour with exceptions and MapSource crashes. Thanks that was a good clue I hope. I modify the size of the section mdr11 in the routine that writes it out. As all the sections depend on each other and need to know their sizes this is too late. I have extracted out the code that changes the section size into a finish() method which is called before anything is written out. I am not in a possition to test it however, but I am sure that the previous code was wrong - the change may not go far enough. ..Steve Thanks Steve, your code changes did not have any effect on my tests so there must be some more things to do. POI search shows exception if MDR12 is put into MDR. But we know for sure that our MDR12 creation has a problem. In mdr_creator.cpp in line 1291 is a difference between mdr8 and mdr12. The lenght of the mdr12 dataset needs place for one more bit. I cannot find any code where the mdr12 gets written out, so I cannot see the meaning of the bit. Would it be the same as usual, an unique flag? Probably not, each 4 char block is unique by design. Btw. I think the sections mdr8 and mdr12 are optional or generated while downloading from mapsource to the device, because they are not written out in mdr_creator. I assume they are needed for speedup searching at the devices. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How does cgpsmapper / cpreview work
Hi Here is what I have done with cpreview. I have managed to compile it on Linux. I could not get it to work when compiled for 64 bits, so I had to compile it for 32 bits. It runs against mkgmap compiled .img files (that are created on the index branch - I had to make a small change to work around a cpreview crash). You need to give the -i flag to cpreview so that it does not need the .idx files. Then I get a mdr file that looks reasonable. However it just does not work - it is not recognised by mapsource and doesn't activate the search button. However since I have never used cgpsmapper, I might just be using it wrong. I will read your link! ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
Hi In mdr_creator.cpp in line 1291 is a difference between mdr8 and mdr12. The lenght of the mdr12 dataset needs place for one more bit. I cannot I will double check, although I probably deal with it. find any code where the mdr12 gets written out, so I cannot see the meaning of the bit. Would it be the same as usual, an unique flag? Probably not, each 4 char block is unique by design. The published cpreview does not write out mdr8 and 12, and I am not sure that it (the cpreview code) is entirely correct anyway. Section mdr17 seems to do a similar thing. I previously thought that the sections 8/12 might be useful for the device, but on thinking about it they cannot be. Mapsource must re-calculate them when you select a subset of all the maps to be transfered. Anyway if mdr12 caused a crash for some people (it never did for me) then we should just remove it for now. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
In mdr_creator.cpp in line 1291 is a difference between mdr8 and mdr12. The lenght of the mdr12 dataset needs place for one more bit. I cannot I will double check, although I probably deal with it. find any code where the mdr12 gets written out, so I cannot see the meaning of the bit. Would it be the same as usual, an unique flag? Probably not, each 4 char block is unique by design. The published cpreview does not write out mdr8 and 12, and I am not sure that it (the cpreview code) is entirely correct anyway. Section mdr17 seems to do a similar thing. I previously thought that the sections 8/12 might be useful for the device, but on thinking about it they cannot be. Why not? The sections are IMO only usefull at the device. Mapsource must re-calculate them when you select a subset of all the maps to be transfered. Good hint. Mapsource must calculate them when not all maps are transfered. And it DOES need a lot of cpu resources for this. So I assume strongly it rebuilds such indexes like this. Anyway if mdr12 caused a crash for some people (it never did for me) then we should just remove it for now. My opinion too. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index: MDR12 breaking POI search
I previously thought that the sections 8/12 might be useful for the device, but on thinking about it they cannot be. Why not? The sections are IMO only usefull at the device. I meant they are not useful because mapsource calculates them on transfer. There may be a flag that says what is sent as I've seen different behaviour with similar files. Of course I could be wrong. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
