[PATCH v1] - Add support for marine (aka extended) types
Ahoy there shipmates, This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps. Extended types are specified as a 6 digit hex number. The first two digits are always 01. An example type is 0x010200 (point type Buoy). Points, lines and polygons can all be given extended types. The cGPSMapper user manual lists all of the types. Note that routable ways cannot have an extended type. If you try to give a road an extended type, it will converted into a line. At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes. It now works well enough to warrant testing on more map data but I am expecting that there will be problems given the extent of the patch and the nature of what it's doing. Please test if you can and report success/failure/etc. Cheers, Mark
Mark Burton wrote:
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps.
Is this patch only for marine types (think --> I have to put my gps into marine mode) or also for any mode, and shown by typfile as used by "garmin's own" topo maps? I'm wondering why the number is 6 digit hex and not 5 digit. Especially for linetypes some more would be really useful. Also it would be nice for POI that you definitely don't want to appear in any search function (like trafficlights, etc....)
Extended types are specified as a 6 digit hex number. The first two digits are always 01. An example type is 0x010200 (point type Buoy).
Points, lines and polygons can all be given extended types.
The cGPSMapper user manual lists all of the types.
Note that routable ways cannot have an extended type. If you try to give a road an extended type, it will converted into a line.
At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes.
It now works well enough to warrant testing on more map data but I am expecting that there will be problems given the extent of the patch and the nature of what it's doing.
Please test if you can and report success/failure/etc.
Cheers,
Mark
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Here's a list of Garmin types. Don't know how recent it is.
On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton<markb@ordern.com> wrote:
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps.
I tested this, and found that it works fine, both on my eTrex and in Roadtrip for Mac OS X. FYI, I did not have to switch to marine mode or anything else to get the symbols to display. (Although some of the symbols didn't look that nice, but I assume they're there for utility and not aesthetics.) So far, I have just tried this with a few types: a lateral buoy symbol and a pier line type. It would probably be nice to get this committed, so more people can experiment with the additional possibilities this can offer.
At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes.
There appears to be significant progress in adding this type of data to OSM. Since the proposed tags attempt to conform to international standards, it should be fairly easy to match these to Garmin types: http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging
Clinton Gladstone <clinton.gladstone@googlemail.com> writes:
On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton<markb@ordern.com> wrote:
This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps.
I tested this, and found that it works fine, both on my eTrex and in Roadtrip for Mac OS X.
FYI, I did not have to switch to marine mode or anything else to get the symbols to display. (Although some of the symbols didn't look that nice, but I assume they're there for utility and not aesthetics.) So far, I have just tried this with a few types: a lateral buoy symbol and a pier line type.
I wonder about using the marine types for inland surveying features, in the glorious struggle trading off rendered accuracy and ability to convey as much information as possible. Probably that's something I'll do privately only, as I can see a lot of objections.
At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes.
Are we still maintaining garmin-features.csv? Perhaps all the used features are already there, but it would be nice to keep it updated to at least all the features we use. I managed to look at a test map and have a pending diff to add a few things.
There appears to be significant progress in adding this type of data to OSM. Since the proposed tags attempt to conform to international standards, it should be fairly easy to match these to Garmin types:
http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging
Wow, following established standards - what a novel concept, but I'm very glad to see it.
Hi Clinton,
On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton<markb@ordern.com> wrote:
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps.
I tested this, and found that it works fine, both on my eTrex and in Roadtrip for Mac OS X.
Excellent.
FYI, I did not have to switch to marine mode or anything else to get the symbols to display. (Although some of the symbols didn't look that nice, but I assume they're there for utility and not aesthetics.) So far, I have just tried this with a few types: a lateral buoy symbol and a pier line type.
On my eTrex, you can choose between various marine icon sets (Garmin, NOAA, International) and there is also an option to have "marine colors".
It would probably be nice to get this committed, so more people can experiment with the additional possibilities this can offer.
As it's fairly unlikely to break maps that don't use any extended types it's probably safe to commit.
At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes.
There appears to be significant progress in adding this type of data to OSM. Since the proposed tags attempt to conform to international standards, it should be fairly easy to match these to Garmin types:
http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging
The author of the OpenSeaMap effort says that there are now two proposed schemes for tagging marine entities. As far as mkgmap is concerned it doesn't really make much difference what the tags are but it would be nice if there was just one tag set to transform rather than 2. However, I do intend to continue work on this soon. Cheers, Mark
participants (4)
-
Clinton Gladstone -
Felix Hartmann -
Greg Troxel -
Mark Burton