Re: [mkgmap-dev] side effects add-pois-to-lines
I use the add-poi-to-lines option only in a few cases (yet), and I don't use it
on every node either, but only in the middle of a road segment
(mkgmap:line2poitype=mid).
One example is on lines tagged with route=ferry opening_hours=*
http://www.openstreetmap.org/browse/way/40326852
route=ferry opening_hours=* mkgmap:line2poitype=mid {name '${name}
(${opening_hours})' | 'operating ${opening_hours}' } [0x6406 resolution 24]
This is a screenshot of my map:
http://img836.imageshack.us/img836/5582/ferryroute.jpg
Before add-poi-to-lines was introduced I used an extra line to render
opening_hours, but the disadvantage is that you often cannot see this info on
the GPS (it displays the streetname only, or in this case where there is no
streetname, it shows the bike route relation name). Other cases that you can
use this are for example incline, smoothness, tracktype, access tags etc.
Greg wrote:
Can you explain when you want to have a POI for every node in a way? It
seems the area-POI code makes one POI for the closed way, and this is
different. (Not trying to be difficult; I really don't get it.)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Location not working in trunk default style
Hi indicates that they should be separated. They could be placed in one file, which would be used by each of the different geometry types. I agree, one file for these should be enough. I did not quite follow you regarding access tags. They do not matter for polygons, do they? For points, they can matter with link-pois-to-ways, which implements access restrictions based on nearby nodes that carry access tags. I put them all together, because they all apply across a range of object types and modify the properties of the object rather than selecting what kind of object it is. Second, perhaps there is a need for two commands include-before and include-after which allow you to do the inclusion either way as appropriate for the situation. Could we have something similar to the #include and #undef in the C preprocessor? For #undef (or whatever it will be called), an example would be a style that is derived from the default style but removes the lines rules for power=line and man_made=*. Removing rules would be tricky with the current implementation. Inclusion would be possible - do you mean randomly named files from the current style? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Hi By default the Ms (Mapsource) flag is set to 1 but you can set it to 0 with Gmaptool: That flag is not set by mkgmap, unless I'm mistaking what is meant. Is this for ones created by mapsource? I have tried it with my Openfietsmap and it worked. However I discovered that my map is transparent. Underneath it appeared the Basecamp basemap, a very rough map with highways that used my custom typ file (with the wrong lines of course). Any ideas how to make this basemap invisible? I think it has something to do with not using the 0x4b background; I dont use it because this causes ghost As far as I know it is only the background that makes the map opaque. shading in Mapsource (zooming in produces a lot of noise, like this example: http://dl.dropbox.com/u/8541959/mapsource%20lines.jpg). If I edit my map with gpsmapedit, I can see this background polygon 4b is still there, but I simply dont have defined it in the typ file because of those unwanted effects in Mapsource. What happens if you put it back into the TYP file, is it still transparent then? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] side effects add-pois-to-lines
Minko ligfiet...@online.nl writes:
Greg wrote:
Can you explain when you want to have a POI for every node in a way? It
seems the area-POI code makes one POI for the closed way, and this is
different. (Not trying to be difficult; I really don't get it.)
I use the add-poi-to-lines option only in a few cases (yet), and I
don't use it on every node either, but only in the middle of a road
segment (mkgmap:line2poitype=mid).
One example is on lines tagged with route=ferry opening_hours=*
http://www.openstreetmap.org/browse/way/40326852
route=ferry opening_hours=* mkgmap:line2poitype=mid {name '${name}
(${opening_hours})' | 'operating ${opening_hours}' } [0x6406
resolution 24]
This is a screenshot of my map:
http://img836.imageshack.us/img836/5582/ferryroute.jpg
Before add-poi-to-lines was introduced I used an extra line to render
opening_hours, but the disadvantage is that you often cannot see this
info on the GPS (it displays the streetname only, or in this case
where there is no streetname, it shows the bike route relation
name). Other cases that you can use this are for example incline,
smoothness, tracktype, access tags etc.
Thanks. I understand why you want to create one POI from a linear
feature. I still don't understand why it would make sense to make a POI
per node. What I'm getting at is that perhaps the line2poi code should
somehow default to making only one synthetic point POI. I have the
impression it didn't, and you were posting code to work around that.
pgpE64aiwvJil.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Steve wrote: That flag is not set by mkgmap, unless I'm mistaking what is meant. Is this for ones created by mapsource? Sorry, I didnt check what happens with gmapsupp.img's generated with mkgmap. I meant indeed gmapsupps created by Mapsource (because I need a working address index). As far as I know it is only the background that makes the map opaque. What happens if you put it back into the TYP file, is it still transparent then? Yes, it doesn't matter. I have tested it also with a few background polygons 0x4b, also non opaque ones, with or without a typ file, all didnt help. The uderlying basemap is still visible through the osm map, and the line style of this basemap is defined by the osm typ file. We have noticed it does not occur with generated maps by cgpsmapper. As workaround I have created an alternative Global Application Basemap v2.gmap which is empty. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] side effects add-pois-to-lines
Greg Troxel schrieb am 27.11.2011 17:12:
I still don't understand why it would make sense to make a POI
per node. What I'm getting at is that perhaps the line2poi code should
somehow default to making only one synthetic point POI.
Below is an example from my points-style, where I generate icons for incline
values set to a line, similar to the highway=incline POIs. Perhaps it would be
enough, to generate a single icon for each way marked with incline=*, but by
generating the icons for all nodes of the way, it is better visible, where the
inlcine starts and where it ends.
Gruss
Torsten
highway=incline
[0x4009 resolution 24 continue]
highway=incline_steep
[0x400a resolution 24 continue]
highway=* mkgmap:line2poitype=* mkmap_incline_type!=done incline ~
'^-?[0-9].*' {set mkmap_incline_type=numeric}
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?[2-9][0-9].*' incline ~ '.*%' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?19.*' incline ~ '.*%' {set name=19%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?18.*' incline ~ '.*%' {set name=18%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?17.*' incline ~ '.*%' {set name=17%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?16.*' incline ~ '.*%' {set name=16%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?15.*' incline ~ '.*%' {set name=15%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?14.*' incline ~ '.*%' {set name=14%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?13.*' incline ~ '.*%' {set name=13%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?12.*' incline ~ '.*%' {set name=12%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?11.*' incline ~ '.*%' {set name=11%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?10.*' incline ~ '.*%' {set name=10%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?9.*' incline ~ '.*%' {set name=9%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?8.*' incline ~ '.*%' {set name=8%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?7.*' incline ~ '.*%' {set name=7%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?6.*' incline ~ '.*%' {set name=6%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?5.*' incline ~ '.*%' {set name=5%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?4.*' incline ~ '.*%' {set name=4%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?3.*' incline ~ '.*%' {set name=3%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?[2-9][0-9].*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?19.*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?18.*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done}
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Hi I meant indeed gmapsupps created by Mapsource (because I need a working address index). Perhaps this is a good time to mention the gmap-mdr branch which is about making a working address index! It is now in a working state, at least for single countries. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Hi The uderlying basemap is still visible through the osm map, and the line style of this basemap is defined by the osm typ file. We have noticed it does not occur with generated maps by cgpsmapper. The attached patch fixes this. ..Steve Index: src/uk/me/parabola/mkgmap/general/MapDetails.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP +UTF-8 === --- src/uk/me/parabola/mkgmap/general/MapDetails.java (revision 2104) +++ src/uk/me/parabola/mkgmap/general/MapDetails.java (revision ) @@ -104,8 +104,8 @@ type = shape.getType(); else type = shape.getType() 8; - if (type != 0x4b00) + - updateOverview(shapeOverviews, type, shape.getMinResolution()); + updateOverview(shapeOverviews, type, shape.getMinResolution()); shapes.add(shape); } ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Thanks Steve, Unfortunately I dont know how to compile a patched mkgmap so I can't test it, but this patch and a search index in gmapsupp is very good news! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
On 27/11/11 21:08, Minko wrote: Thanks Steve, Unfortunately I dont know how to compile a patched mkgmap so I can't test it, but this patch and a search index in gmapsupp is very good news! OK I committed it to the branch, so you can get it from the download page along with the address index. You just give --index along with --gmapsupp and the index is created inside the gmapsupp.img. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Thanks Steve, I tested mkgmap-gmap-mdr-r2125.jar: - Transparency in Basecamp: solved! See http://img821.imageshack.us/img821/3453/gmap.jpg The map is bordered by a thin blue line, which is normal. Underlying basemap is not visible anymore. One issue: there is a small thin blue line within the map, east of Aachen until north of Eschweiler. If I select this area in mapsource, it looks like this tile is split in two, but in reality it is just one tile: http://img215.imageshack.us/img215/8567/tileso.jpg It is this tile in my areas list: 10010058: 2361344,274432 to 2369536,307200 # : 50.668945,5.888672 to 50.844727,6.591797 - Adress search Works in Nuvi and Dakota. Can't locate any Dutch cities though, only streetnames. It can locate addresses in Belgium and German cities. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] License text
Hi,
ok, here is my last and final patch for the copyright/license
informations in MapSource/Basecamp/Garmin Device.
Works now for me in all cases I can test.
Thorsten
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (Revision 2109)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (Arbeitskopie)
@@ -21,6 +21,11 @@
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
+import java.io.BufferedReader;
+import java.io.File;
+import java.io.FileNotFoundException;
+import java.io.FileReader;
+import java.io.IOException;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.Exit;
@@ -51,6 +56,7 @@
import uk.me.parabola.imgfmt.app.trergn.Subdivision;
import uk.me.parabola.imgfmt.app.trergn.TREFile;
import uk.me.parabola.imgfmt.app.trergn.Zoom;
+import uk.me.parabola.imgfmt.ExitException;
import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.Version;
import uk.me.parabola.mkgmap.filters.BaseFilter;
@@ -125,6 +131,8 @@
private LBLFile lblFile;
+ private String licenseFileName;
+
public MapBuilder() {
regionName = null;
locator = new Locator();
@@ -149,6 +157,8 @@
poiAddresses = false;
routeCenterBoundaryType = props.getProperty(route-center-boundary, 0);
+
+ licenseFileName = props.getProperty(license-file, null);
locator = new Locator(props);
}
@@ -695,19 +705,42 @@
//
// We use it to add copyright information that there is no room for
// elsewhere.
- map.addInfo(OpenStreetMap and contributors);
- map.addInfo(www.openstreetmap.org);
- map.addInfo(Map data licenced under Creative Commons Attribution ShareAlike 2.0);
- map.addInfo(http://creativecommons.org/licenses/by-sa/2.0/;);
+ if (licenseFileName != null) {
+ File file = new File(licenseFileName);
+ StringBuffer contents = new StringBuffer();
+ BufferedReader reader = null;
- // Pad the version number with spaces so that version
- // strings that are different lengths do not change the size and
- // offsets of the following sections.
- map.addInfo(Map created with mkgmap-r
+ try {
+ reader = new BufferedReader(new FileReader(file));
+ String text = null;
+
+ // repeat until all lines is read
+ while ((text = reader.readLine()) != null) {
+ if (text.length() 0) {
+ map.addInfo(text);
+}
+ }
+
+ reader.close();
+ } catch (FileNotFoundException e) {
+ throw new ExitException(Could not open license file + licenseFileName);
+ } catch (IOException e) {
+ throw new ExitException(Error reading license file + licenseFileName);
+ }
+ } else {
+ map.addInfo(OpenStreetMap and contributors);
+ map.addInfo(www.openstreetmap.org);
+ map.addInfo(Map data licenced under Creative Commons Attribution ShareAlike 2.0);
+ map.addInfo(http://creativecommons.org/licenses/by-sa/2.0/;);
+
+ // Pad the version number with spaces so that version
+ // strings that are different lengths do not change the size and
+ // offsets of the following sections.
+ map.addInfo(Map created with mkgmap-r
+ String.format(%-10s, Version.VERSION));
- map.addInfo(Program released under the GPL);
-
+ map.addInfo(Program released under the GPL);
+ }
// There has to be (at least) two copyright messages or else the map
// does not show up. The second one will be displayed at startup,
// although the conditions where that happens are not known.
Index: src/uk/me/parabola/mkgmap/reader/osm/OsmMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/OsmMapDataSource.java (Revision 2109)
+++ src/uk/me/parabola/mkgmap/reader/osm/OsmMapDataSource.java (Arbeitskopie)
@@ -112,10 +112,9 @@
* @return A list of copyright messages as a String array.
*/
public String[] copyrightMessages() {
- return new String[] {
-OpenStreetMap.org contributors,
-See: http://wiki.openstreetmap.org/index.php/Attribution;
- };
+ String note = getConfig().getProperty(copyright-message,
+ OpenStreetMap.org contributors. See: http://wiki.openstreetmap.org/index.php/Attribution;);
+ return new String[] { note };
}
protected void setStyle(Style style) {
Index: resources/help/en/options
===
--- resources/help/en/options (Revision 2109)
+++ resources/help/en/options (Arbeitskopie)
@@ -230,6 +230,14 @@
number used in the overview map and tdb file. The default
number is 6324.
+--copyright-message=note
+ Specify a copyright message for files that do not contain one.
+
Re: [mkgmap-dev] Location not working in trunk default style
Am Sonntag 27 November 2011, 15:34:31 schrieb Steve Ratcliffe:
Hi
indicates that they should be separated. They could be placed in one
file, which would be used by each of the different geometry types.
I agree, one file for these should be enough. I did not quite follow you
regarding access tags. They do not matter for polygons, do they? For
points, they can matter with link-pois-to-ways, which implements access
restrictions based on nearby nodes that carry access tags.
I put them all together, because they all apply across a range of
object types and modify the properties of the object rather than
selecting what kind of object it is.
Second, perhaps there is a need for two commands include-before and
include-after which allow you to do the inclusion either way as
appropriate for the situation.
Could we have something similar to the #include and #undef in the C
preprocessor? For #undef (or whatever it will be called), an example
would be a style that is derived from the default style but removes the
lines rules for power=line and man_made=*.
Removing rules would be tricky with the current implementation.
Inclusion would be possible - do you mean randomly named files from
the current style?
..Steve
IMO a #include statement that behaves like in C/C++ or even better like the
source statement within a shell script would be sufficient and much better
than the current base-style technique. The statement should be allowed at
any position within a stylefile and 'sources' the stated file line by line
exactly at that position. At the moment i archive this by generating the
styles with some cat commands before any mkgmap call.
Preventing double inclusion of a file is not so important for me, cause it may
or may not make sense including the same ruleset twice at different positions
within the 'final' ruleset.
Specifying the files to include platformindependent with relative and absolute
paths or relative to the 'default style' paths would be helpful. Examples:
source ../mystyletemplates/locatorrules.txt
#include default/locator.rules
#def and #undef is IMO not so useful at all, cause you allways are able to
prevent the execution of a rule by catching the element within another rule
given before the rule you want to 'undef'.
Allowing an empty element type definition or a keyword 'next' or
'abort_element' comparable to the awk script 'next' statement would help much
more keeping the style files simple and readable. Example:
highway=residential mynamespace:not_usable=yes [ next ]
or
highway=residential mynamespace:not_usable=yes [ next ]
or
highway=residential mynamespace:not_usable=yes {abort}
would prevent any further processing of the elements matching the condition.
If this is already implemented please let me know, did not see it within the
examples or the documentation.
Regards
Hasemann
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Location not working in trunk default style
On Mon, Nov 28, 2011 at 12:45:30AM +0100, Olaf Hasemann wrote: #def and #undef is IMO not so useful at all, cause you allways are able to prevent the execution of a rule by catching the element within another rule given before the rule you want to 'undef'. You are right, the #undef would merely allow the OSM parser to drop uninteresting tags (saving memory). For a relatively rare tag, such as power=line, this should not make much difference. For more widely-used tags, you would probably be better off omitting the include/source/base-style for the tags you are not interested in. Allowing an empty element type definition or a keyword 'next' or 'abort_element' comparable to the awk script 'next' statement would help much more keeping the style files simple and readable. Example: highway=residential mynamespace:not_usable=yes [ next ] To my knowledge, this has not been implemented. I am not entirely convinced of the usefulness. This should be fairly easy to implement, basically replace the convertNode(), convertWay() calls with a no-op when the keyword is present. The [] stuff is parsed in osmstyle/TypeReader.java. Maybe we could simply have a special flag in GType that tells to omit the conversion in convertWay(), convertNode() and the like? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
