Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Felix Hartmann wrote: SRTM2OSM mainly produced huge output files, much bigger than needed. groundtruth is much better in that respect. Groundtruth needs tons of RAM. I didn't manage to run it for whole Germany data, but SRTM2OSM did that just fine on the same 4 GB RAM machine. ___ 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
What I actually do is to include the contour lines into the IMG file, because that works best for me. If you put them into a separate IMG file and then the polygons into a separate IMG file and also the ways into their separate IMG file you can create layers and control the draw order - in a way. We just lately had a discussion about this on the mailing list, see the thread 'Option "preserve-element-order"'. Regards Thilo Am 04.07.2009 um 22:42 schrieb Christian Gawron: Thilo Hannemann schrieb: I think using one IMG has the advantage that using a TYP file you can specify the drawing order (first the "background" polygons, than the contours, then the streets). Actually, using different IMG files will allow you to do that, but with one IMG file for everything it will be difficult. You cannot specify the drawing order of ways in the TYP file, only of polygons. And as I understand it, it is not easy to control the drawing order of ways in any other way. Nop seems to be able to do it by controlling the order the ways are written into the IMG file, but I was largely unsucessfull using that method. But if you put the IMG with the contours on top, wouldn't the contour lines be on top of the ways? And if you do it the other way around, wouldn't the background polygons (eg. forrest) hide the contour lines? How did you solve this? I actually tried using separate IMG files first, but I didn't get "nice" results, so I used XInclude to include the contour lines from the OSM file (before I wrote the code to create the contour lines in mkgmap). Best wishes Christian ___ 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] [PATCH] Creating contour lines from DEM data
Thilo Hannemann schrieb: I think using one IMG has the advantage that using a TYP file you can specify the drawing order (first the "background" polygons, than the contours, then the streets). Actually, using different IMG files will allow you to do that, but with one IMG file for everything it will be difficult. You cannot specify the drawing order of ways in the TYP file, only of polygons. And as I understand it, it is not easy to control the drawing order of ways in any other way. Nop seems to be able to do it by controlling the order the ways are written into the IMG file, but I was largely unsucessfull using that method. But if you put the IMG with the contours on top, wouldn't the contour lines be on top of the ways? And if you do it the other way around, wouldn't the background polygons (eg. forrest) hide the contour lines? How did you solve this? I actually tried using separate IMG files first, but I didn't get "nice" results, so I used XInclude to include the contour lines from the OSM file (before I wrote the code to create the contour lines in mkgmap). 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! Felix Hartmann schrieb: SRTM2OSM mainly produced huge output files, much bigger than needed. groundtruth is much better in that respect. Unfortunately, groundtruth is not yet capable of simply creating contour lines within a given bounding box, it always forcibly breaks it up in segments and changes the bounding box size. It looks like Christians work is a good step towards an srtm2osm alternative. 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
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. That seems very cool, and I look forward to trying it. It would be nice to have a few intermediate abilities (I've read most the rest of the thread by now): output osm format data from the DEM (for other use, or later use, or for intermediate reprocessing) make an img that's transparent with the DEM data, not only for licensing reasons but also because it really seems like something the user would want to flip off sometimes. For the first point, my immediate reaction was that it was too bad this was in mkgmap instead of a standalone utility, but I see the intermediate storage issue. Having the code in mkgmap is not a big deal, and it enables the nice behavior of an internal pipeline. This isn't really related to your work, but it seems to me that mkgmap has grown tons of options, and modern recommended usage is to have a lot of them on. It would be nice if every option had a negative form and there was a --best-practice option that enabled all the ones that are recommended for making the best garmin maps (complete with tdb etc. for turning into gmapi, and everything else one would need). Right now it seems a little hard to use, where everyone has to chase down those options and write a script. I can certainly see where at one time each of these options might have caused trouble and thus was not default, and the notion that behavior shouldn't change for compatibility. But I also wonder how many users really want that rather than just to make a img file for their receiver. pgp9TT5r5LTIJ.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] [PATCH] Creating contour lines from DEM data
Am 04.07.2009 um 13:06 schrieb Christian Gawron: Nop schrieb: And I don't agree that this would be a derived work. OSM does not contain any DEM data or contour lines, so by adding them the OSM layer remains unchanged and clearly discernible from the contour lines, so I would say the result is a collective work. Discernible is not enough. You need to read through the full legalese. A collective work is defined as a collection of unmodified entities. This is definitely not true for a gmapsupp.img. Took me a while to understand and believe how bad the current OSM licence is, too. Thank you for the clarification. So maybe I should add an option to put the contours into a separate IMG file. Right now you could achieve this by using an input file which contains no data but the bounding box. I think using one IMG has the advantage that using a TYP file you can specify the drawing order (first the "background" polygons, than the contours, then the streets). Actually, using different IMG files will allow you to do that, but with one IMG file for everything it will be difficult. You cannot specify the drawing order of ways in the TYP file, only of polygons. And as I understand it, it is not easy to control the drawing order of ways in any other way. Nop seems to be able to do it by controlling the order the ways are written into the IMG file, but I was largely unsucessfull using that method. Regards Thilo ___ 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: And I don't agree that this would be a derived work. OSM does not contain any DEM data or contour lines, so by adding them the OSM layer remains unchanged and clearly discernible from the contour lines, so I would say the result is a collective work. Discernible is not enough. You need to read through the full legalese. A collective work is defined as a collection of unmodified entities. This is definitely not true for a gmapsupp.img. Took me a while to understand and believe how bad the current OSM licence is, too. Thank you for the clarification. So maybe I should add an option to put the contours into a separate IMG file. Right now you could achieve this by using an input file which contains no data but the bounding box. I think using one IMG has the advantage that using a TYP file you can specify the drawing order (first the "background" polygons, than the contours, then the streets). 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! Christian Gawron schrieb: I don't see any difference between merging externally generated contour lines into one IMG file or generating the contour lines with mkgmap - the resulting IMG file looks the same. The difference is what is being published: You may not create a map from both sources and redistribute it. But you may distribute each layer seperately and let the end user combine them into a map, which he may not redistribute. And I don't agree that this would be a derived work. OSM does not contain any DEM data or contour lines, so by adding them the OSM layer remains unchanged and clearly discernible from the contour lines, so I would say the result is a collective work. Discernible is not enough. You need to read through the full legalese. A collective work is defined as a collection of unmodified entities. This is definitely not true for a gmapsupp.img. Took me a while to understand and believe how bad the current OSM licence is, too. 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
Nop schrieb: Hi! I am very much interested in your work as I used srtm2osm, which is no longer working, and now I am looking for alternate techniques. Christian Gawron schrieb: 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). Should not be too difficult to make this configurable and also turn off the elevation texts for each level. No need to label each 10m-line. Maybe I should use the styling engine here - I will have a look at it. What determines the area in which the contour lines are calculated? The bounding box of the tile. So each map tile must have a bounding box? What happens if there is none? Currently I am not generating them, but that's no problem. AFAIK the mapper generates a bounding box, but this may be too large. 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. This is still a problem. When creating a map of Germany, I have 440 tiles, but I cannot tell in advance which of them are too mountaineous too show with all altitude lines. Even if nothing crashes, if you show 10m lines for the whole of the alps, the map size will explode and the map consists mostly of altitude lines. In the past, I have handled it by first creating the contour line .osm with srtm2osm and 10m lines. When the size of the output .osm was too large, I doubled the base distance to 20m lines and tried again, until the output size was within limits. Can you think of a way to integrate an upper limit for elevation lines and a try-and-error fitting against this limit to your calculations? Or even better, is there a way to predict the outcome without doing all calculations first? I could add a feature which looks at the difference between minimum and maximum height in a tile and chose the interval based on this. 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
Thilo Hannemann schrieb: -- 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. I don't see any difference between merging externally generated contour lines into one IMG file or generating the contour lines with mkgmap - the resulting IMG file looks the same. And I don't agree that this would be a derived work. OSM does not contain any DEM data or contour lines, so by adding them the OSM layer remains unchanged and clearly discernible from the contour lines, so I would say the result is a collective work. But of course anyone planning to distribute such maps should check this more thoroughly (maybe the guys who are hosting the cycle layer or the "Wanderkarte" did this). 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! Christian Gawron schrieb: 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. To put it very simple: The share-alike cause of the OSM licence requires you to make everything available under the OSM licence again. If you combine OSM with other data which has _any_ form of restrictions or any different interpretation of freeness, you are breaking one of the licences. A common workaround is to add the combined data in an extra layer and claim this makes a collective work. This is not legally sound, but has never been challenged. I am putting my hope in the new licence which would allow you to create such a combined work. 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! I am very much interested in your work as I used srtm2osm, which is no longer working, and now I am looking for alternate techniques. Christian Gawron schrieb: 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). Should not be too difficult to make this configurable and also turn off the elevation texts for each level. No need to label each 10m-line. What determines the area in which the contour lines are calculated? The bounding box of the tile. So each map tile must have a bounding box? What happens if there is none? Currently I am not generating them, but that's no problem. 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. This is still a problem. When creating a map of Germany, I have 440 tiles, but I cannot tell in advance which of them are too mountaineous too show with all altitude lines. Even if nothing crashes, if you show 10m lines for the whole of the alps, the map size will explode and the map consists mostly of altitude lines. In the past, I have handled it by first creating the contour line .osm with srtm2osm and 10m lines. When the size of the output .osm was too large, I doubled the base distance to 20m lines and tried again, until the output size was within limits. Can you think of a way to integrate an upper limit for elevation lines and a try-and-error fitting against this limit to your calculations? Or even better, is there a way to predict the outcome without doing all calculations first? 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
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] [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
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] 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)
