Documentation improvements for sea processing,
Hi Gerd, Please find attached a patch to improve the documentation of sea processing plus minor changes to --add-pois-to-lines. I note that extend-sea-sectors says "Adds a point so coastline reaches the nearest tile boundary. This implies no-sea-sectors". But no-sea-sectors disables the generation of sea sectors when the coastline fails to reach the tile's boundary, so I would have thought that extend-sea-sectors is an alternative action and would imply that no-sea-sectors is off. Cheers, Mike
Hi Mike & Gerd No problems with this. Concerning *-sea-sectors. My reading of the documentation implies extend-sea-sectors and no-sea-sectors are alternatives. The comprehension difficulty is because of the naming of 'extend-sea -sectors', which are very different from the 'sea-sectors' that 'no-sea -sectors' stops. 'sea-sectors' isn't a good name either because they could be 'land-sectors'. Probably not worth thinking about this any further. Ticker On Tue, 2021-02-16 at 20:23 +0000, Mike Baggaley wrote:
Hi Gerd,
Please find attached a patch to improve the documentation of sea processing plus minor changes to --add-pois-to-lines.
I note that extend-sea-sectors says "Adds a point so coastline reaches the nearest tile boundary. This implies no-sea-sectors". But no-sea -sectors disables the generation of sea sectors when the coastline fails to reach the tile's boundary, so I would have thought that extend-sea-sectors is an alternative action and would imply that no-sea-sectors is off.
Cheers, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, - reg. --add-pois-to-lines (and also ----add-pois-to-areas) I think the texts (and of course the option names) are misleading. The program doesn't generate "POI", it just generates additional nodes with special tags and the point rules decide what to do with those nodes. I noticed this because of the new text "An extra point added by mkgmap at the middle of the line". Really, mkgmap adds a new node for all existing nodes of the unclosed way AND one extra node for the calculated middle of the way. Some of the added nodes may be filtered, e.g. when two consecutive "inner" nodes have the same Garmin position. I think the most important thing about nodes created by the --add-pois-to-lines option is that the user probably has to add rules to ignore most of those nodes. - Reg. "=== Sea Processing options ===" I don't like the word "either" in this section. This implies that you cannot use --precomp-sea together with --generate-sea while the text for --precomp-sea says you can. - The --generate-sea option can always be used to overwrite these defaults: generate-sea=multipolygon,landtag=natural=land The default tag natural=land tag is also used in the precomp-sea data, and e.g. generate-sea: land-tag=natural=background can be used to change that. No idea why, found this option in the "Openfietsmap full" style together with these polygon rules: natural=land [0x27 resolution 20] natural=background [0x010100 resolution 12] - I don't understand the sentence "Must be used in conjunction with the --generate-sea option." for --coastlinefile option. I guess this only applies when data like that in "gbcoastline-unfixed.zip" is used. - I think the docu for --precomp-sea should point out that one can download that data from http://www.mkgmap.org.uk/download/mkgmap.html and that it typically is the best option (I don't know any good alternative) I see no need for a normal user to compile precomp-sea data, but the needed steps are shown in https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompil... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 17. Februar 2021 11:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Documentation improvements for sea processing, Hi Mike & Gerd No problems with this. Concerning *-sea-sectors. My reading of the documentation implies extend-sea-sectors and no-sea-sectors are alternatives. The comprehension difficulty is because of the naming of 'extend-sea -sectors', which are very different from the 'sea-sectors' that 'no-sea -sectors' stops. 'sea-sectors' isn't a good name either because they could be 'land-sectors'. Probably not worth thinking about this any further. Ticker On Tue, 2021-02-16 at 20:23 +0000, Mike Baggaley wrote:
Hi Gerd,
Please find attached a patch to improve the documentation of sea processing plus minor changes to --add-pois-to-lines.
I note that extend-sea-sectors says "Adds a point so coastline reaches the nearest tile boundary. This implies no-sea-sectors". But no-sea -sectors disables the generation of sea sectors when the coastline fails to reach the tile's boundary, so I would have thought that extend-sea-sectors is an alternative action and would imply that no-sea-sectors is off.
Cheers, Mike _______________________________________________ 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
Hi Gerd, I've further edited the documentation in the light of your comments - see below inline.
- reg. --add-pois-to-lines (and also ----add-pois-to-areas) I think the texts (and of course the option names) are misleading. The program doesn't generate "POI", it just generates additional nodes with special >tags and the point rules decide what to do with those nodes. I noticed this because of the new text "An extra point added by mkgmap at the middle of the line". Really, mkgmap adds a new node for all existing nodes of the unclosed way AND one extra node for the calculated middle of the way. Some of the >added nodes may be filtered, e.g. when two consecutive "inner" nodes have the same Garmin position.
I've removed the references to "POIs" and replaced them with "nodes", and added a mention of the points file being used to produce the POIs.
I think the most important thing about nodes created by the --add-pois-to-lines option is that the user probably has to add rules to ignore most of >those nodes.
I've added a sentence to cover this.
- Reg. "=== Sea Processing options ===" I don't like the word "either" in this section. This implies that you cannot use --precomp-sea together with --generate-sea while the text for -->precomp-sea says you can.
I've removed "either".
- The --generate-sea option can always be used to overwrite these defaults: generate-sea=multipolygon,landtag=natural=land
The documentation indicates that under --precomp-sea.
The default tag natural=land tag is also used in the precomp-sea data, and e.g. generate-sea: land-tag=natural=background can be used to change >that. No idea why, found this option in the "Openfietsmap full" style together with these polygon rules: natural=land [0x27 resolution 20] natural=background [0x010100 resolution 12]
- I don't understand the sentence "Must be used in conjunction with the --generate-sea option." for --coastlinefile option. I guess this only applies >when data like that in "gbcoastline-unfixed.zip" is used.
If you use --coastlinefile on its own it has no effect. You have to use --generate-sea with it. I have clarified the sentence. Perhaps specifying --coastlinefile should switch on --generate-sea=multipolygon like --precomp-sea does.
- I think the docu for --precomp-sea should point out that one can download that data from http://www.mkgmap.org.uk/download/mkgmap.html and >that it typically is the best option (I don't know any good alternative)
I have added a reference to the URL (I have not made it a link as the options builder doesn't support links as far as I remember).
I see no need for a normal user to compile precomp-sea data, but the needed steps are shown in https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompi led_sea_yourself
I do not think mkgmap documentation should reference the OSM wiki (I don't think it should be referenced on the index page either, as it gives the impression that the OSM wiki is the prime place for information). If there is any useful information about mkgmap on the OSM wiki that is not in the mkgmap documentation, then this information needs adding to the mkgmap documentation. Cheers, Mike
participants (3)
-
Gerd Petermann -
Mike Baggaley -
Ticker Berkin