Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Am 04.07.2009 um 08:04 schrieb Christian Gawron: A very good hint. The understanding of all discussions on the matter is that the current OSM licence does not allow mixing with CIAT data nor with ASTER data. So you cannot publish those maps. Could you elaborate on this? I would understand that e.g. the license of the ASTER data forbids publishing of derived work (although I haven't checked this). But is there really a point in the OSM license which forbids creating derived works (maps) which as an "add-on" contain features created from proprietary data sources? Yes it is. See the section "I created a layer on top of an OSM map. What do I have to put under your license?" from http://wiki.openstreetmap.org/wiki/Common_licence_interpretations : -- You have to determine whether what you have created is a Collective Work or a Derivative work, under the terms of the OSM licence. • If what you create is based on OSM data (for example if you create a new layer by looking at the OSM data and refering to locations on it) then it is likely you have created a derivative work. • If you generate a merged work with OSM data and other data (such as a printed map or pdf map) where the non-OSM data can no longer be considered to be separate and independent from the OSM data, is is likely you have created a derivative work. • If you overlay OSM data with your own data created from other sources (for example you going out there with a GPS receiver) and the layers are kept separate and independent, and the OSM layer is unchanged, then you may have created a collective work. If you have created a derivative work, the work as a whole must be subject to the OSM licence. If you have created a collective work, then only the OSM component of the work must be subject to the OSM licence. -- So especially with your solution to integrate the contour lines into the map this is IMHO a derivative work, so that all components of it must be subject to the OSM license. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Route recalculation; error circle
Probably a related report by another user: " Re- calculation was also fast most of the time, typically taking less than 10 seconds. In some cases it immediately recalculated as soon as I went off route. I noticed however that I'm unable to calculate a route when my starting position is off road. Even if I'm just a few feet to the side of the road eg sidewalk, I'm unable to calculate a route to any destination. " On Sat, Jul 4, 2009 at 2:05 PM, Marko Mäkelä wrote: > I made some observations on my Edge 705 yesterday. The route recalculation > sensitivity varies in bicycle mode. Sometimes, I can ride a couple hundred > metres until getting a notice; other times, I get the notice within a couple > dozen metres. > > This might have something to do with junctions and parallel roads. Once, > I rode on a cycleway that is almost parallel to the calculated route. In > the next junction, it told me to turn the right way, even though the > current position was indicated correctly. > > Another observation: I can confirm what someone said earlier about the > error circle around the current position marker. Even though the GPS > accuracy is something like 5 metres most of the time, the radius of the > error circle on the map is something like 20 metres. It will get bigger > when there are obstructions, such as tunnels or tall buildings. > > Marko > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Route recalculation; error circle
I made some observations on my Edge 705 yesterday. The route recalculation sensitivity varies in bicycle mode. Sometimes, I can ride a couple hundred metres until getting a notice; other times, I get the notice within a couple dozen metres. This might have something to do with junctions and parallel roads. Once, I rode on a cycleway that is almost parallel to the calculated route. In the next junction, it told me to turn the right way, even though the current position was indicated correctly. Another observation: I can confirm what someone said earlier about the error circle around the current position marker. Even though the GPS accuracy is something like 5 metres most of the time, the radius of the error circle on the map is something like 20 metres. It will get bigger when there are obstructions, such as tunnels or tall buildings. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
A very good hint. The understanding of all discussions on the matter is that the current OSM licence does not allow mixing with CIAT data nor with ASTER data. So you cannot publish those maps. Could you elaborate on this? I would understand that e.g. the license of the ASTER data forbids publishing of derived work (although I haven't checked this). But is there really a point in the OSM license which forbids creating derived works (maps) which as an "add-on" contain features created from proprietary data sources? Best wishes Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Nop schrieb: Sounds interesting. Does it also distinguish minor and major elevation lines? Currently the types are still hard-coded as follows: multiples of 200m: 0x22 multiples of 50m: 0x21 0x20 for all others This should of course be configurable (as well as a "feet" mode). What determines the area in which the contour lines are calculated? The bounding box of the tile. Is there a way to avoid an overload with contours e.g. when processing the whole of Germany inclduing very flat country as well as the the alps? You may split the map and use diffeent settings for each tile. Best wishes Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Hi! Thilo Hannemann schrieb: As there are some people on this list who will publish their created maps I'll have to add a caveat though: You should make sure that the data source you use for the generation of the contour lines is compatible with the OSM license. See http://wiki.openstreetmap.org/wiki/Legal_FAQ and http://wiki.openstreetmap.org/wiki/Common_licence_interpretations. The reason why I bring that up is that for example the improved SRTM data by CIAT-CSI is in my opinion *not* compatible with the OSM license! A very good hint. The understanding of all discussions on the matter is that the current OSM licence does not allow mixing with CIAT data nor with ASTER data. So you cannot publish those maps. bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Hi! Christian Gawron schrieb: the attached java classes together with the patch enables mkgmap to create contour lines directly from digital elevation model (DEM) data. This may be useful for those who don't want to ceate contour lines with other tools and store them in huge(!) files. It introduces the following new options: --contours If set, create contours. --dem-type Valid values are CGIAR (CGIAR geotiff), ASTER (ASTER geotiff) or SRTM (.hgt files). Default is CGIAR. --dem-path Path to the DEM data files. The default is type-dependant. --dem-increment Verical distance between the contour lines (default is 10m). Sounds interesting. Does it also distinguish minor and major elevation lines? What determines the area in which the contour lines are calculated? Is there a way to avoid an overload with contours e.g. when processing the whole of Germany inclduing very flat country as well as the the alps? bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1078: Fix bugs in date/time encoding in headers.
Version 1078 was commited by markb on 2009-07-04 01:43:14 +0100 (Sat, 04 Jul 2009) Fix bugs in date/time encoding in headers. Hour is now modulo 24 and not modulo 12. In one place, year had 1900 erroneously subtracted from it. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Relations and roles
I want to show road signs for restrictions. So I tried the following:
relations:
type=restriction { apply { set relation_restriction='${restriction}' }}
points:
relation_restriction=only_straight_on [0x300f level 0]
This creates a sign at the crossing. But I'd prefer to see the sign at the
'from' part of the relation. So I added the following line to the file
polygons:
relation_restriction=only_straight_on [0x21 level 0]
In this case I get 3 signs for every restriction (from, via, to). (This is a
'hack' to get a POI for a way with --add-pois-to-areas. The polygon is not
displayed because the way consists of 2 nodes).
How can I restrict the POI to the 'from' member of the relation? The
following line doesn't work because 'role' doesn't belong to the relation,
it belongs to the members of the relation:
type=restriction & role=from { apply { set
relation_restriction='${restriction}' }}
Rudi
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Several cycle networks over the same way
I have some cycle networks that share the same ways. This means that a road
belongs to more than one cycle network. In this case I want to see the ref
of the cycle networks in the name of the road, e.g. " (RRM, VBT,
MWW)".
My file 'relations' contains this line:
type=route & route=bicycle { apply { set route_name='${ref}' }}
In this case the tag route_name of the way is set for every route and the
last one wins. So I tried:
type=route & route=bicycle & route_name!=* { apply { set route_name='${ref}'
}}
type=route & route=bicycle & route_name=* { apply { set
route_name='${route_name}, ${ref}' }}
This doesn't work because we have no access to the tags of the way.
Who has an idea how I can join the different names?
Rudi
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Hi Christian, congratulations, that is very good work. As there are some people on this list who will publish their created maps I'll have to add a caveat though: You should make sure that the data source you use for the generation of the contour lines is compatible with the OSM license. See http://wiki.openstreetmap.org/wiki/Legal_FAQ and http://wiki.openstreetmap.org/wiki/Common_licence_interpretations. The reason why I bring that up is that for example the improved SRTM data by CIAT-CSI is in my opinion *not* compatible with the OSM license! Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Patch so that the --add-pois-to-areas option applies actions defined in the points style file and takes the POI name from there
This one is a little complicated: When using the --add-pois-to-areas option, for every shape whose tags will match an entry in the points style file, a POI entry in the map will be created in the center of the shape (if there is not already one POI with the same name inside the shape). The POI will have the name of the *shape* and no actions from the points style file will be applied. I think that is not how it should be. One of the most important cases for this option is when you have an POI that is in the OSM data as a building (close way with "building=yes") carrying the tags for the POI. You might now have lots of name-tweaking rules in you points style file to generate nice looking names for hotels, etc. But in the polygons style file there is a single entry that handles all tags with "building=yes". What you now get is that all the name-tweaking rules *are not applied* if the POI comes in the form of a shape, only if it comes as a single node. To get around this you had to duplicate your name-tweaking for each POI in the polygons style file. This will need lots of rules that from the perspective of the polygons style file all will do the same: generate a shape for a building. So this patch will modify the behaviour so that a POI that is generated from a shape will have all the actions defined in the points style file applied to it and that it will also get the name defined by the points style file. modify_generate_pois_from_areas.patch Description: Binary data Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Creating contour lines from DEM data
Dear all,
the attached java classes together with the patch enables mkgmap to
create contour lines directly from digital elevation model (DEM) data.
This may be useful for those who don't want to ceate contour lines with
other tools and store them in huge(!) files.
It introduces the following new options:
--contours If set, create contours.
--dem-type Valid values are CGIAR (CGIAR geotiff), ASTER (ASTER
geotiff) or SRTM (.hgt files). Default is CGIAR.
--dem-path Path to the DEM data files. The default is type-dependant.
--dem-increment Verical distance between the contour lines (default is 10m).
The algorithm used is a modified version of that described in "An
Adaptive Grid Contouring Algorithm" by Downing and Zoraster (see
http://mapcontext.com/autocarto/proceedings/auto-carto-5/pdf/an-adaptive-grid-contouring-algorithm.pdf)
and uses bicubic interpolation of the DEM.
Please feel free to send me improvements, bug reports etc.
Best wishes
Christian
Index: src/uk/me/parabola/mkgmap/Option.java
===
--- src/uk/me/parabola/mkgmap/Option.java (Revision 1077)
+++ src/uk/me/parabola/mkgmap/Option.java (Arbeitskopie)
@@ -34,7 +34,7 @@
}
}
- protected Option(String option, String value) {
+ public Option(String option, String value) {
this.option = option;
this.value = value;
}
Index: src/uk/me/parabola/mkgmap/CommandArgsReader.java
===
--- src/uk/me/parabola/mkgmap/CommandArgsReader.java(Revision 1077)
+++ src/uk/me/parabola/mkgmap/CommandArgsReader.java(Arbeitskopie)
@@ -129,7 +129,7 @@
* @param option The option name.
* @param value Its value.
*/
- private void addOption(String option, String value) {
+ public void addOption(String option, String value) {
CommandOption opt = new CommandOption(option, value);
addOption(opt);
}
@@ -181,13 +181,21 @@
return arglist.iterator();
}
+public ArgList getArgList() {
+ return arglist;
+ }
+
+public EnhancedProperties getArgs() {
+ return args;
+ }
+
/**
* Read a config file that contains more options. When the number of
* options becomes large it is more convenient to place them in a file.
*
* @param filename The filename to obtain options from.
*/
- private void readConfigFile(String filename) {
+ public void readConfigFile(String filename) {
Options opts = new Options(new OptionProcessor() {
public void processOption(Option opt) {
log.debug("incoming opt", opt.getOption(),
opt.getValue());
@@ -206,14 +214,14 @@
* the argument to be processed in order. Options can be intersperced
with
* filenames. The options take effect where they appear.
*/
- interface ArgType {
+ public interface ArgType {
public abstract void processArg();
}
/**
* A filename.
*/
- class Filename implements ArgType {
+ public class Filename implements ArgType {
private final String name;
private boolean useFilenameAsMapname = true;
@@ -270,7 +278,7 @@
/**
* An option argument. A key value pair.
*/
- class CommandOption implements ArgType {
+ public class CommandOption implements ArgType {
private final Option option;
private CommandOption(Option option) {
@@ -297,7 +305,7 @@
/**
* The arguments are held in this list.
*/
- class ArgList implements Iterable {
+ public class ArgList implements Iterable {
private final List alist;
private int filenameCount;
Index: src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java
(Revision 1077)
+++ src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java
(Arbeitskopie)
@@ -33,6 +33,7 @@
import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.dem.DEM;
import uk.me.parabola.util.Configurable;
import uk.me.parabola.util.EnhancedProperties;
@@ -146,5 +147,8 @@
// the overview section.
mapper.addShape(background);
}
+ if (getConfig().getProperty("contours", false)) {
+ DEM.createContours(mapper, getConfig());
+ }
}
}
/*
* Copyright (C)
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
[mkgmap-dev] Commit: r1077: Polish input reader now recognises codes like ~[0x05].
Version 1077 was commited by steve on 2009-07-03 14:42:32 +0100 (Fri, 03 Jul 2009) Polish input reader now recognises codes like ~[0x05]. ___ 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] Commit: r1073: Add highway shields and other ways of modifying values in the style files.
A side effect of this commit is to make address search even less usable than it was before (surely not possible, I hear you say) because it redefines a road's name to include its reference and the highway shield thingy (if appropriate). So, for example, a road called "Letsbe Avenue" (where all the police live) that has a reference A123 will now get assigned the name "A123 Letsbe Avenue" (plus the shield code if the road type warrants it) and so it will show up in the address search in the A section rather than the L section (not sure what the shield code does for search). 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. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1076: Make highway shield work with 6-bit labels.
Version 1076 was commited by steve on 2009-07-03 12:26:02 +0100 (Fri, 03 Jul 2009) Make highway shield work with 6-bit labels. Add a test for the shield substitution. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1075: Pipeline and more contours in default style.
Version 1075 was commited by steve on 2009-07-03 11:57:05 +0100 (Fri, 03 Jul 2009) Pipeline and more contours in default style. -Ondrej Novy ___ 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
Paul Ortyl wrote: 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." ? That statement is not true with the current splitter version. When splitting North/South America I get 318 tiles. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
