idea for the manual

Miika Turkia miika.turkia at gmail.com
Wed Dec 10 08:56:24 PST 2014


On Wed, Dec 10, 2014 at 5:20 PM, Dirk Hohndel <dirk at hohndel.org> wrote:

> On Wed, Dec 10, 2014 at 03:12:18PM +0000, Pedro Neves wrote:
> > Subsurface's XML format supports four coordinate formats according to the
> > manual:
> >
> > "The coordinates can be entered by hand if they are known, using one of
> four
> > formats with latitude followed by longitude:
> > ISO 6709 Annex D format e.g. 30°13'28.9"N 30°49'1.5"E
> > Degrees and decimal minutes, e.g. N30° 13.49760' , E30° 49.30788'
> > Degrees minutes seconds, e.g. N30° 13' 29.8" , E30° 49' 1.5"
> > Decimal degrees, e.g. 30.22496 , 30.821798
> > Southern hemisphere latitudes are given with a S, e.g. S30°, or with a
> > negative value, e.g. -30.22496. Similarly, western longitudes are given
> with
> > a W, e.g. W07°, or with a negative value, e.g. -7.34323."
> >
> > However I can only import GPS coordinates from a .CSV file if they are
> > expressed as decimal degrees (and without a comma separating latitude and
> > longitude): "30.22496 30.821798". All the other formats result in empty
> > coordinates on Subsurface.
> >
> > I'm not sure if this has to do with the import filter code or with my
> > locale, but it would be helpfull if someone could run a few tests on
> other
> > machines just to make sure. I'm inclined to write that the GPS
> coordinates
> > on the .CSV file have to follow the format "dd.dddd dd.dddd", with a "-"
> for
> > S latitudes and W longitudes
>
> This is almost certainly Miika's input filter... we have some rather
> fragile C++ functions to parse all the other formats, but I don't think he
> can easily call those from XSLT...
>

bug, fixing...

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141210/6b93a947/attachment.html>


More information about the subsurface mailing list