idea for the manual

Miika Turkia miika.turkia at gmail.com
Wed Dec 10 09:37:43 PST 2014


On Wed, Dec 10, 2014 at 6:56 PM, Miika Turkia <miika.turkia at gmail.com>
wrote:

> 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...
>

Well, it seems that the GPS location is always internally in the decimal
format. Thus I cannot just pass the string to Subsurface processing. We
should probably use the GUI function for GPS parsing, if we want to allow
more flexible GPS format for the import. (It really does not make sense to
try parse these in XSLT.)

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


More information about the subsurface mailing list