BSB driver to interpret PLY border polygon records at a header

[vadp]

Current BSB driver does not interpret border polygon records (PLY) at a KAP file header. Hence a resulting image contains non-chart raster data, mostly -- white chart borders.

All PLY records at BSB header define an external border of a usable chart data area at BSB raster (navigabve boundaries). Each PLY record describes a node of this polygon. A format to PLY record is:

PLY/<num>,<latitude>,<longtitude>

where <num> is a sequential number of a polygon node; <latitude>,<longtitude> are the coordinates of a node;

Here is a sample of PLY record set:

PLY/1,42.848493354,17.669935397
PLY/2,42.848476901,17.833244816
PLY/3,42.848498863,18.310012913
PLY/4,42.750101633,18.310063433
PLY/5,42.583347680,18.309925613
PLY/6,42.519703886,18.309939725
PLY/7,42.519743095,18.000004138
PLY/8,42.519736633,17.669913981
PLY/9,42.583380432,17.670003492
PLY/10,42.666775490,17.670020630
PLY/11,42.750096134,17.670037729

Latitude, longtitude values are given according to local chart's datum, so they must be altered according to DTM record content to bring them into WGS84 (see ticket #3172)

[vadp]

bsb2tiff-cut.sh -- proof of the concept script to convert BSB KAP chart into TIFF file with cut raster

[hamish]

the polygon described by PLY/n is the navigable part of the map. Outside area should still be exported to GDAL, as it contains important things like the map title and projection/scale info which you want to keep.

If something is to be done for PLY, my humble suggestion would be to export a second raster band with a 0/1 coverage of out/inside of the polygon. Like a pseudo version of the HDF format which includes a Quality bit band along with the actual data.

As far as I've been able to figure out you can only have one bounding polygon and it can not have holes in it.

Hamish

[vadp]

Replying to hamish:

the polygon described by PLY/n is the navigable part of the map. Outside area should still be exported to GDAL, as it contains important things like the map title and projection/scale info which you want to keep.

Basically the PLY polygon describes the part of the raster which contains representation of the Earth's features. Map title and projection/scale info, etc represent metadata, and this information must be already presented at the BSB header.

On the other hand, such a polygon is a very valuable data. Imagine automated mosaicking or mere automatic chart swap at some navigation application. Anyway, I'm not suggesting to throw away these data. I understand GDAL already has a feature to store such a polygon, so this is up to an application how to interpret it.

Actually I've already made python script in which generates a virtual raster out of a .kap file which contains a polygon description in there, so I'm attaching it for the reference.

[vadp]

Replying to vadp:

Latitude, longtitude values are given according to local chart's datum, so they must be altered according to DTM record content to bring them into WGS84 (see ticket #3172)

BTW As PLY data are to be converted into pixel coordinates, it does not really matter if you take into account DTM data, as the local gcs would suffice for the purpose. This is how it's implemented at kap2vrt.py script.

[hamish]

altered according to DTM record content to bring them into WGS84 (see ticket #3172)

thanks for explaining what DTM/0,0 does. It has been confusing me for a while. I have been taking the datum just from the KNP/GD=WGS84, but my files all just have DTM/0,0. which manuf? any of those use PR=TRANSVERSE MERCATOR? I have been trying to understand the projection settings for those too.

Map title and projection/scale info, etc represent metadata, and this information must be already presented at the BSB header.

perhaps, but the KAP file only supports a small set of metadata options, while the image may have info on tides, vertical datum of +elevations (bridges, topolines, radio towers), etc. etc. etc.

regards, Hamish

ps- test platform: www.opencpn.org

pps- trac keeps logging me out (server reset?), which eats anything I've typed into the comment box as soon as I hit [preview]. very frustrating. back-arrow in the web browser doesn't preserve the entry text so I have to retype it.

[vadp]

Replying to hamish:

I have been taking the datum just from the KNP/GD=WGS84, but my files all just have DTM/0,0.

Basically all the European charts that I saw up to the moment have non-WGS84 datums hence they have non-zero DTM data. Some state their datum quite vaguely, like "GD=Local Datum". In this case DTM record is the only way to bring them to something meaningful.

which manuf? any of those use PR=TRANSVERSE MERCATOR? I have been trying to understand the projection settings for those too.

So far I've found only one German map-set on the Net that uses Transverse Mercator. I think Google search could bring you there. The projection parameters there seems to be quite understandable.

KAP file only supports a small set of metadata options, while the image may have info on tides, vertical datum of +elevations (bridges, topolines, radio towers), etc. etc. etc.

That's correct, as above even datum information sometimes incomplete. On the other hand raster image data is not (easily) machine readable. I'm not really literate with GDAL's internals, but my understanding that its cutline feature merely defines Earth features region at a raster, that's how PLY data perfectly fits into this. Otherwise, something like this worth introducing (like Ozi's Moving Map Parameters?).

I think if an application needs a full raster it could just disregard a catline (import option?). BTW alpha layer could be yet another way for dealing with that.

ps- test platform: www.opencpn.org

opencpn seems to be a great thing. Unfortunately with my Nokia n810 I can use only maemo-maps, that's why I'm so interested in automated mosaicking where PLY data is essential.

pps- trac keeps logging me out (server reset?),

There is no problem for me here: I use firefox 3.6 at ubuntu.

[hamish]

any of those use PR=TRANSVERSE MERCATOR? I have been trying to understand the projection settings for those too.

Replying to vadp:

So far I've found only one German map-set on the Net that uses Transverse Mercator. I think Google search could bring you there.

the closest I could find is this link, for "German Baltic Sea"

​http://www.busse-yachtshop.de/dae_fugawi.html

is that the set of charts you mean?

The projection parameters there seems to be quite understandable.

could you please cut an paste a small example of the KAP header that I can learn from?

interested in automated mosaicking where PLY data is essential.

I'm not convinced that gdalwarping in-view raster tiles to a common projection in real-time is computationally justifiable. But I guess it depends on the grunt and screen size of your mobile device. I'd be happy to be proved wrong by a working prototype.

regards, Hamish <hamish_b * yahoo * com>

[manimaul]

Both scripts, bsb2tiff-cut.sh and kap2vrt.py, produce completely transparent output for me using NOAA chart ​http://opencpn.org/tmp/18453_1.KAP and GDAL 1.7.1

Boiling it down for kap2vrt.py:

$./kap2vrt.py 18453_1.KAP
produces files: 18453_1.aux.vrt 18453_1.cut.gmt 18453_1.vrt

$gdal_translate -of png 18453_1.aux.vrt 18453_1.png
the produced png is same as original chart...as expected

$gdal_translate -of png 18453_1.vrt 18453_1.png
the produced png is completely transparent

ps - I had to comment out line #39 on kap2vrt.py to get it to run since the 18453_1.KAP header begins with ! not BSB/

Boiling it down for bsb2tiff-cut.sh:

$./bsb2tiff-cut.sh 18453_1.KAP
produces files: 18453_1.KAP.vrt 18453_1.KAP.csv 18453_1.KAP.tiff, the tiff file is completely transparent

[vadp]

Replying to hamish:

the closest I could find is this link, for "German Baltic Sea"

​http://www.busse-yachtshop.de/dae_fugawi.html

is that the set of charts you mean?

Hi Hamish, I've sent you the link, so have a look.

I'm not convinced that gdalwarping in-view raster tiles to a common projection in real-time is computationally justifiable. But I guess it depends on the grunt and screen size of your mobile device. I'd be happy to be proved wrong by a working prototype.

Actually I don't use gdalwarping in real time. Instead after my script I run gdal2tiles.py (where gdalwarping happens anyway), when join a few pyramids to cover a larger area, and then download a "mosaicked" pyramid into my gadget.

[vadp]

Replying to manimaul:

Both scripts, bsb2tiff-cut.sh and kap2vrt.py, produce completely transparent output for me using NOAA chart ​http://opencpn.org/tmp/18453_1.KAP and GDAL 1.7.1

I use GDAL 1.6.3, so that's might be an reason. I'll check that chart when I have a bit of time

[vadp]

Replying to manimaul:

Both scripts, bsb2tiff-cut.sh and kap2vrt.py, produce completely transparent output for me using NOAA chart ​http://opencpn.org/tmp/18453_1.KAP and GDAL 1.7.1

I've checked 18453_1.KAP, it seems fine for me as I use GDAL 1.6.3. It must be something changed with gdalwarp. Unfortunately I don't have 1.7.1 yet to check.

ps - I had to comment out line #39 on kap2vrt.py to get it to run since the 18453_1.KAP header begins with ! not BSB/

18453_1.KAP is BSB version 3. Version 2 (always?) had "BSB/" at the 2nd line. I've fixed that, but still not able to check with GDAL 1.7.1

[vadp]

Replying to manimaul:

Both scripts, bsb2tiff-cut.sh and kap2vrt.py, produce completely transparent output for me using NOAA chart ​http://opencpn.org/tmp/18453_1.KAP and GDAL 1.7.1

To work with GDAL 1.6.x a warp cutline contained mere pixel coordinates. In GDAL 1.7.x this doesn't work. It looks like a cutline needs to have some srs assigned, otherwise gdalwarp treats it as if it has the same srs as a raster file. So I've changed the kap2vrt.py to put an srs into a cutline.

[vadp]

This seems to work better with BSB v3, GDAL 1.6.x and GDAL 1.7.x

[manimaul]

vadp... perfect, new kapt2vrt.py works like a charm, tested on transmercator projected charts also. email me if you would like some swedish chart samples that are transmercator projection.

manimaul --- at --- gmail --- com

[warmerdam]

I must confess I have not been following this ticket closely. Should I be moving this script (kap2vrt.py) into the GDAL svn tree?

[hamish]

fyi

for testing, NOAA chart 14500 is Polyconic not Merc. (free download from NOAA's RNC site)

Hamish

[hamish]

minor suggestion for kap2vrt.py:

-wgs84_latlong='+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs'
+wgs84_latlong='+proj=longlat +datum=WGS84'

is enough

[vadp]

Replying to manimaul:

tested on transmercator projected charts also

Cheers manimaul! I think that the script shouldn't be really accurate (if not worse) with Transverse Mercator as there is no any projection check in it (yet). It just forces normal Mercator, hence I'd imagine it should be some problem with the Transverse.

[vadp]

Replying to hamish:

minor suggestion for kap2vrt.py:

-wgs84_latlong='+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs'
+wgs84_latlong='+proj=longlat +datum=WGS84'

is enough

Thanks hamish. How is about this one?

wgs84_merc='+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs' 

[vadp]

Replying to hamish:

for testing, NOAA chart 14500 is Polyconic not Merc. (free download from NOAA's RNC site)

Transverse Mercator, then Polyconic -- cool! will have a look...

[manimaul]

Replying to warmerdam:

I must confess I have not been following this ticket closely. Should I be moving this script (kap2vrt.py) into the GDAL svn tree?

I'd say that this definitely deserves to be in swig/python/samples.

[vadp]

Replying to hamish:

fyi

for testing, NOAA chart 14500 is Polyconic not Merc. (free download from NOAA's RNC site)

I'm uploading a new version with poly and tmerc support. The results look rather convincing, but it would be great to check it closely. BTW did you manage to puzzle BSB params for these projections?

[vadp]

some support for Polyconic and Transverse Mercator, cutting is optional

[vadp]

Hello. I'm posting a newer version of bsb reader script. Now it supports some native datums and projections. DTM shifts and raster croppings are now optional.

[vadp]

UTM and workaround for #3777

[vadp]

Perhaps, no worth flooding this thread with unrelated issues, so for ones interested in, the latest version of the bsb2gdal.py can be found here ​http://talk.maemo.org/showthread.php?t=57469

[warmerdam]

Kurt and I might look into integrating this, perhaps in the samples directory.

[vadp]

Replying to warmerdam:

Kurt and I might look into integrating this, perhaps in the samples directory.

Alex, the script is now a part of ​tilers-tools

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.