Re: [mkgmap-dev] Description text
Toby Speight (t.m.speight...@cantab.net) wrote: POIs with address information have this in their description when viewed on my eTrex, but the generation of this appears to be hard-coded. It would be nice to be able to have different information in there - opening hours for shops, or telephone numbers for pubs and hotels, for example. So, would it be possible to make this more general? I'm thinking of having a tag, say mkgmap:description, that if set would be used for this content. Then our style rules could be used to apply the above. ___ A similar thought occurred to me recently. For instance, the emerging information=* tags (http://wiki.openstreetmap.org/wiki/Proposed_features/information) can contain a lot of information that would be useful to be able to access on a GPS device (via the POI address). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
Hi,
It would be great to be able to add more information to the pois.
At the moment the information that can be seen is streetname, number, postal
codes and placenames
in the properties of some of the pois (the gps can't show this properties box
on all kinds of pois unfortunately)
I have been experimenting to 'fool' my Garmin to use addr:streetname etc for
some other information and this trick worked.
tourism=information
{
add addr:street='${opening_hours}';
add addr:postcode='${website}' ;
add addr:city='${note}' ;
} [0x resolution ..]
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap and relation 406175
On Mon, Apr 12, 2010 at 12:51 PM, Apollinaris Schoell ascho...@gmail.com wrote: relation looks good. You should try to create just a single tile first to see if it's mkgmap or splitter. splitter clips ways from relations outside of the tile and this is a known problem. recent versions of mkgmap can repair in most cases by closing the multipolygon at the tile boundary. But it doesn't work in very complex situations. I see similar problems on large lakes, national park, … I just tried it with a single .osm file that was not processed with splitter and the relation is not rendered. I used the XAPI to download the extract rather than using the planet file this time around. I verified that the relation is completely included in the extract. I've put the source files and the results athttp://161.210.45.126/ if someone wants to take a look. I have one note: The wiki tells us something about tagging of multipolygons: It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways. This means: if only one of the ways used for the relation is not completely tagged it may break the complete multipolygon. The mp 406715 does not follow this rule. I don't know if that's a problem or not but you may consider to tag the multipolygon instead of all ways. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Do not process boundary relations
At the moment processing of multipolygon boundary relations creates a lot of unwanted effects (artificial boundaries on tile bounds, lots of warnings etc.). The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. An additional spin-off is the improved performance and less warnings. WanMil Can you please commit this patch? I think this patch is quite needed unless we have a good overall working concept for such relations and it definitely removes the ugly boundary lines on tile borders. Thanks! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Recycling menu items in the Oregon
Hi! In the Oregon text strings can be easily changed since they are defined in xml-files in a directory inside the flash file system. I recycled now e.g. truckstop (0x2f16) to amenity=taxi. #amenity=fuel fuel:HGV_diesel=yes [ 0x2f16 resolution 19 ] must be commented out in the point file, amenity=taxi [0x2f16 resolution 20] added. In the german.gtt file in Garmin/text, I changed str tagTXT_Truck_Stop_STR/tag txtTruckstop/txt /str to str tagTXT_Truck_Stop_STR/tag txtTaxistand/txt /str And I added an icon in my typfile and now I can search for the next taxi point. :-) Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
Toby Speight wrote: POIs with address information have this in their description when viewed on my eTrex, but the generation of this appears to be hard-coded. It would be nice to be able to have different information in there - opening hours for shops, or telephone numbers for pubs and hotels, for example. So, would it be possible to make this more general? I'm thinking of having a tag, say mkgmap:description, that if set would be used for this content. Then our style rules could be used to apply the above. Easier (with the existing code) would be IMHO to hardcode more information and add descriptional lines (Address: ... Phone number: ... Website: ...) etc. Sometimes there are phonenumbers added, but they cannot easily be recognized as phone numbers since thy lack the prefixes. One time, I thought they were artifacts from the generating code instead of phone numbers. :-) The possible keys are really well defined, so it is easy for an experienced Java-Programmer to add a few new functions. That would also be easier to implement and it would not be necessary to change someting in the interface or style files. I looked at the Java-code: it would really just need some new functions that are pretty equal to the existing ones. You would just need the new mkgmap and see a lot more information. :-) Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
Minko wrote:
Hi,
It would be great to be able to add more information to the pois.
At the moment the information that can be seen is streetname, number, postal
codes and placenames
in the properties of some of the pois (the gps can't show this properties box
on all kinds of pois unfortunately)
I have been experimenting to 'fool' my Garmin to use addr:streetname etc for
some other information and this trick worked.
tourism=information
{
add addr:street='${opening_hours}';
add addr:postcode='${website}' ;
add addr:city='${note}' ;
} [0x resolution ..]
That is a nice idea, but I really think, that the yet already hardcoded
information should be expanded on more tags.
Dani
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
On Thu, Apr 15, 2010 at 01:02:08PM +0200, Minko wrote: I have been experimenting to 'fool' my Garmin to use addr:streetname etc for some other information and this trick worked. Is the addr:* translation currently hardcoded in mkgmap? Where is it? I found one oddity last year: addr:housenumber='12-14' (should probably be 12;14 in the OSM notation) was displayed as 12 Apt 4 if I remember correctly. Also, I find the English-style order of housenumber street and city zip backwards. To my knowledge, continental Europe uses street housenumber and zip city. I think that the correct way to implement the translation would be via the style file. The style file would compose a mkgmap:description from the addr:*, phone, opening_hours, website, url, description and whatnot, based on the type of the POI as needed. Are there any fixed fields, such as phone number encoded in some special format? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
Marko Mäkelä wrote: Is the addr:* translation currently hardcoded in mkgmap? Where is it? I think here: MapBuilder.java Search for FIX MY ADDRESS. Around it there are function calls like p.getStreet() and so on. I think here could be (new) functions like p.getWebsite and so on called. I found one oddity last year: addr:housenumber='12-14' (should probably be 12;14 in the OSM notation) was displayed as 12 Apt 4 if I remember correctly. Also, I find the English-style order of housenumber street and city zip backwards. To my knowledge, continental Europe uses street housenumber and zip city. Perhaps these were incorrectly tagged? The java code seems to put the information it receives into the information screen on your Garmin. There seems to be no translation whatsoever. You could try to add logging information in the java code and get a small part of the area you want to debug from the osm-data. Then you have either a file that can be easiliy loaded into an editor and you can see what mkgmap makes out of it. I think that the correct way to implement the translation would be via the style file. The style file would compose a mkgmap:description from the addr:*, phone, opening_hours, website, url, description and whatnot, based on the type of the POI as needed. Are there any fixed fields, such as phone number encoded in some special format? I think that that would be too much. It would be better (IMHO) to just expand a little the existing code and leave the style files as they are. The benefit would be, that millions of style-file users would have to do nothing. They would afterwards just see a lot more information in their Garmin units. Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recycling menu items in the Oregon
And there are many other things that can be easily recycled. Have you ever been lost in an unknown city and asked yourself: Where is the next hot spring? Garmin thinks that finding hot springs is essential, so they gave them a menu item. Dani P.S: Etrex Users can do the same, but they have no possibility to change the unused strings to better ones. They must search for truckstops and keep in mind, that these are taxis. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
On Thu, Apr 15, 2010 at 11:52:41PM +0200, Daniela Duerbeck wrote: I think here could be (new) functions like p.getWebsite and so on called. I think that it would be better to use the mkgmap: name space for it. The style definition would translate the attributes to, say, mkgmap:description, and the core of mkgmap would copy that attribute to the Garmin format. I found one oddity last year: addr:housenumber='12-14' (should probably be 12;14 in the OSM notation) was displayed as 12 Apt 4 if I remember correctly. Also, I find the English-style order of housenumber street and city zip backwards. To my knowledge, continental Europe uses street housenumber and zip city. Perhaps these were incorrectly tagged? No, I am seeing this for all POIs, and the 12-14 was something that I tagged myself. Say, I have an address Hauptstraße 1 12345 Musterstadt It will be displayed as 1 Haupstraße Musterstadt 12345 Are you seeing the same? If I remember correctly, I saw it in this format in the gmapsupp.img too. I think that the correct way to implement the translation would be via the style file. The style file would compose a mkgmap:description from the addr:*, phone, opening_hours, website, url, description and whatnot, based on the type of the POI as needed. Are there any fixed fields, such as phone number encoded in some special format? I think that that would be too much. It would be better (IMHO) to just expand a little the existing code and leave the style files as they are. The benefit would be, that millions of style-file users would have to do nothing. Are there really that many style files in circulation? For backward compatibility, we could keep the old behaviour when no mkgmap:description attribute exists. Anyone who wants anything fancier will tweak the style file or use the default style. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
