[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58854] [octave forge] (mapping) kmlread does

From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #58854] [octave forge] (mapping) kmlread does not handle id tags when trying to parse placemark text
Date: Tue, 4 Aug 2020 14:15:09 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #13, bug #58854 (project octave):

Couldn't resist having a look (turns out my daughter prepares dinner tonight
rather than me so I have a brief spell)

As I wrote over in bug #58701 (gpxread), comment #5:
> mixed time format fields are going to be a big PITA. That is because
Octave's datenum function (like Matlab's) isn't smart enough to parse a date
string vector with varying formats.
... no matter how valid Google declares it to be for kml files :-(

Of course, in theory preparing for different date/time formats in a vector
should be possible but in practice it's going to be a complicated affair
having fragile results at best.
Luckily Google standardized the formats a bit. So checking the lengths using

cellfun ("numel", times);

...followed by filling in missing month/day/hour/minute/second strings with
zeros for each string < 20 chars could be a way out.  However time zone
corrections (the last time format in comment #9) would screw up royally.

So inserting:

      ltime = cellfun ("numel", times);
      if (any (ltime < 20))
        ## Year resolution
        times(ltime == 4) = ...
         cellfun (@(x) [x "-00-00T00:00:00Z"], times(ltime == 4), "uni", 0);
        ## Month resolution
        times(ltime == 7) = ...
         cellfun (@(x) [x "-00T00:00:00Z"], times(ltime == 7), "uni", 0);
        ## Day resolution
        times(ltime == 10) = ...
         cellfun (@(x) [x "T00:00:00Z"], times(ltime == 10), "uni", 0);

after L.194 solves reading 2020-50km-Course.kml time fields (I just

As to the missing elevation in COURSE_20667693.kml, that fix was just needed
for Points and involved an easy check on nr. of coordinates.

OK, fixes pushed here:
(I took the liberty of crediting you for your assistance)
and kmlread.m attached, please try, hopefully it works well enough.

(file #49628)

Additional Item Attachment:

File name: kmlread.m                      Size:8 KB


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]