I think this is no longer needed, now that jest is dropped.

Parsing a tcx file I noticed that heartRates coordinate property are not added to the final geojson feature properties.

Repro:

1. Open up this glitch example: https://glitch.com/edit/#!/defiant-unleashed-ghoul
2. Click Show -> Next to code
3. Open up the console and inspect the feature in geojson -> it has a coordTimes, but not heartRates.
4. Notice that the original dataset has HeartRateBpm: https://github.com/RalucaNicola/togeojson/blob/raluca/heartRateTcx/test/data/tour_hr.tcx

I am using Google My Maps and I have noticed in the newer versions of this conversion tool, it is now adding a label-color that matches the icon-color when it should not be present. It did not used to do this in previous versions. It also is now not reading in the label-scale property when it used to as well.

I forked your online tool so that it used the latest version of this library and that is where you can reproduce what I'm seeing by uploading the KML files I have provided in the ZIP file below.

The fork can be found here: https://observablehq.com/d/96ff9e6b1b6edfb1

This is a snippet of the attached KML file below

      <IconStyle>
        <color>ffd18802</color>
        <scale>1</scale>
        <Icon>
          <href>https://www.gstatic.com/mapspro/images/stock/503-wht-blank_maps.png</href>
        </Icon>
        <hotSpot x="32" xunits="pixels" y="64" yunits="insetPixels"/>
      </IconStyle>
      <LabelStyle>
        <scale>0</scale>
      </LabelStyle>
      <BalloonStyle>
        <text><![CDATA[<h3>$[name]</h3>]]></text>
      </BalloonStyle>
    </Style>

When I import using the latest conversion tool I get

As you can see, it is adding the label-color to match the icon-color while also not adding the label-scale at all.

When uploading to a previous version it converts to

It properly gives no label-color and sets the label-scale to 0

Google My Maps Placemark.kml.zip

Thanks and let me know if I can clarify anything else

I'm undertaking a bit of a refactor of this project, and something I'm strongly considering is removing style hashing. I added the styleHash property to styles years ago in hopes that it'd support usecases in which the identity of "a style" is useful. I haven't found any of those cases, and I suspect that it's mostly ignored by all users of this module. It introduces a bit of complexity and generally doesn't seem worthwhile, and I also suspect that it's a performance drag.

So, a bit of a question: is this an essential feature for anyone?

I have created simple kml with one placemark and one polygon, styled placemark icon and polygon color but none of the styles are in the GeoJSON feature properties.

Output GeoJSON:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          21.00062301000721,
          48.77257131826958,
          1011.317797185818
        ]
      },
      "properties": {
        "name": "Untitled Placemark",
        "styleUrl": "#__managed_style_04D1BA179420769B4A67",
        "styleMapHash": {
          "normal": "#__managed_style_1AF19DBC7E20769B4A67",
          "highlight": "#__managed_style_21BB934A3420769B4A67"
        },
        "description": "<div>Ahoj <b>PM</b></div>"
      },
      "id": "00A083AD2520769B213A"
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              20.99533143425753,
              48.76385474037835,
              817.5844849086294
            ],
            [
              21.00506376944139,
              48.76355632184772,
              896.3736545453368
            ],
            [
              21.00499721332549,
              48.77057344889175,
              1026.856093377534
            ],
            [
              20.99495695589513,
              48.77073832155815,
              991.0859038879247
            ],
            [
              20.99533143425753,
              48.76385474037835,
              817.5844849086294
            ]
          ]
        ]
      },
      "properties": {
        "name": "Untitled Polygon",
        "styleUrl": "#__managed_style_01C13F4A1E20769D5922",
        "styleMapHash": {
          "normal": "#__managed_style_1CAC85685820769D5922",
          "highlight": "#__managed_style_24D42D73B520769D5922"
        }
      },
      "id": "0F66A23B9820769D44FC"
    }
  ]
}

Should styles be included or it is just not supported by the library?

Thank you

Should be pretty doable and helpful here.

This could be outside of the responsibility, but 🤷‍♂️seems fine to include.

There are now quite a few style properties converted from KML - it would be helpful to have a table showing what turns into what.

IE10 is the target: this should use map and some basic modern JavaScript. microbundle will Bublé it down to a common superset.

Options:

• Look for the kml tag, if it is not found, return an error.

I think it's fine to import/cross-import this stuff.

After a quick re-install of my app, I get the following error

export 'kml' (imported as 'kml') was not found in '@tmcw/togeojson' (module has no exports)

package.json: 4.5.0^
Installed version: 4.6.0

This was not an issue in 4.5.0

This took some 🔍 so reporting here in case it catches others out:

I've been using togeojson successfully until we happened upon a KML which would always return zero features, e.g:

const text = await response.text();
const xml = new window.DOMParser().parseFromString(text, "text/xml");
const json = kml(xml);
console.log(url, json.features.length)

//  file.kml 0

More confusingly running in node or the CLI would find them correctly, e.g:

$ npx @tmcw/togeojson-cli file.kml | jq -e '.features | length'
18

I tracked it down to the file.kml not having this in its kml tag:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

I'm not sure if that is supposed to be there or why it differs between the browser and xmldom? 🤔

I am using a the packages in a nodejs Typescript based project, where I launch the code using ts-node, but I am getting an undefined when I used the import:

import toGeoJson from '@tmcw/togeojson';

Looking at the source of 4.1.0 suggests I should be using named imports, per https://github.com/tmcw/togeojson/blob/master/index.js

Does this mean the docs are out of date or there is a missing default export?

Note this code does work:

import { kml } from '@tmcw/togeojson';

const data = fs.readFileSync(inputFile, 'utf8')
const kmlData = new DOMParser().parseFromString(data);

CrossWGS.kml.txt
Attached file errors on upload at https://observablehq.com/@tmcw/convert-kml-to-geojson and gives error of "geojson = Error: This page contains the following errors:error on line 3 at column 211: Namespace prefix xsi for schemaLocation on Document is not defined
Below is a rendering of the page up to the first error."

Is this a bug or invalid kml or something else?

What it says on the tin.

Hey there,

happy to see this project is still maintained - thank you for that!

One question I'd like to raise is if there are plans to map the .gpx styles to the .geojson format as well. The so-called "Geojson CSS" markup is used for that and could be applied from the gpxx:DisplayColor GPX attribute. I could contribute that change if the general idea is approved by you.

Thanks!

EDIT: It seems like basic styles are already supported here but it seems limited to certain styles. The latest Garmin routes have a format as following:

  <rte>
    <name>27.05.2020 Tour 5_357 km_zyanblau</name>
    <extensions>
      <gpxx:RouteExtension>
        <gpxx:IsAutoNamed>false</gpxx:IsAutoNamed>
        <gpxx:DisplayColor>Cyan</gpxx:DisplayColor>
      </gpxx:RouteExtension>
      <trp:Trip>
        <trp:TransportationMode>Motorcycling</trp:TransportationMode>
      </trp:Trip>
    </extensions>
    ...
  </rte>

I need to support NMEA, TRK and OZI formats for one of my projects on top of GPX and KML.

Would you be interested to merge the code in this repo ? (I would write the conversion to geojson).

Thanks,
Victor

I try to browserify , but run into error,

            `browserify index.js --s togeojson -o dist/togeojson.js

              /Users/nicole/node/togeojson/index.js:1
               export { gpx, gpxGen } from "./lib/gpx";
              ^
              ParseError: 'import' and 'export' may appear only with 'sourceType: module'

I wrote geojson-merge. It's easy to implement merging, and probably both expected and convenient to the users of this module.

I tried to use v >= 5, however this error occurs:

ERROR in node_modules/@tmcw/togeojson/dist/index.d.ts(8,42): error TS2315: Type 'Generator' is not generic.
node_modules/@tmcw/togeojson/dist/index.d.ts(27,42): error TS2315: Type 'Generator' is not generic.
node_modules/@tmcw/togeojson/dist/index.d.ts(82,42): error TS2315: Type 'Generator' is not generic.

When I used version 4.7, I found the following errors:

But I can't install in that directory.
Can you help me, please?

In a KML you can extend the "default" elements in this way:

<Schema parent="Placemark" name="S_country">  
    <SimpleField type="wstring" name="CNTRY_NAME">
    </SimpleField> 
    </SimpleField>
    <SimpleField type="wstring" name="CURR_TYPE">
    </SimpleField>
    <SimpleField type="wstring" name="CURR_CODE">
    </SimpleField>
  </Schema>
  <S_country>
	<name>Test</name>
        <Point>
		<coordinates>16.54,40.6</coordinates>
	</Point>
        <CURR_TYPE>Test</CURR_TYPE>
	<CNTRY_NAME>Test</CNTRY_NAME>
	<CURR_CODE>Test</CURR_CODE>
  </S_country>

With such a KML this library returns an empty list of features.

Is there any plan to support KML containing custom KML schema? Is this functionality considered in the scope of this library?

This'd allow the main package to drop minimist and get-stdin.

First of all, thanks for giving the much needed love to this library in the recent months! It became so good now that I decided to deprecate my LibKML / GDAL fallback code and only use togeojson for KML imports.

There is only one issue I have with this library, is that it silently drops KML items without valid coordinates. Now this might sound like an edge case, but Google My Maps is exporting more and more maps without coordinates.

I did some experimenting and for a few items on a map added via "Add to Map" it still allows exporting with coordinates, but I've seen reports that with hundreds of items it simply disables coordinate export. It also disables coordinate export for all items which were imported from a CSV.

For example this is how it looks online, showing coordinates:

Whereas this is what is exported:

<Placemark>
  <name>Sherlock Holmes</name>
  <address>221B Baker Street, London</address>
  <description>221B Baker Street, London</description>
  <styleUrl>#icon-1899-0288D1</styleUrl>
</Placemark>

I've created a sample map with both type of items. Here is the KML export (renamed to .txt for GitHub):

KML export test.txt

Right now, togeojson silently drops these items. I'd like to ask to please don't drop these, but add them with null geometry. From the GeoJSON specs, I found this:

The value of the geometry member SHALL be either a Geometry object as 
defined above or, in the case that the Feature is unlocated, a JSON null value.

I think this is exactly the case we are talking here, "unlocated" features.

KML supports layers. toGeoJSON ignores then and just gives you all the features in your KML file.

Strawman draft:

output = toGeoJSON.kmlLayered(xmlDocument);
output = [
{
  layer: 'foo',
  geojson: { type: 'FeatureCollection', /* … */ }
},
{
  layer: 'bar',
  geojson: { type: 'FeatureCollection', /* … */ }
}
]

The correct way to separate tuples in the coordinates field is to separate them with a space, but I saw some kml documents that used a comma instead:

<LineString>
   <coordinates>13.08925,37.517,0,13.0859,37.517,0</coordinates>
   <altitudeMode>relativeToGround</altitudeMode>
</LineString>

Google Earth parses them correctly, so is there any chance that this library will support this out-of-spec syntax?

This is a gross method that's a sticking point for our node / browser compatibility. For hashing styles, we don't need a full-fledged serialization step. Possibly I can use isEqualNode instead, or manually serialize only a subset.

Hello @tmcw !

We're currently using v4.3.0 (also tested in v4.2.0) of togeojson.

When calling tj.kml with this kml file in our React v16.12.0 production app, based on create-react-app, We get the following console error:

TypeError: u is not a function
    at kml.js:296
    at l (runtime.js:63)
    at Generator._invoke (runtime.js:293)
    at Generator.next (runtime.js:118)
    at Function.from (<anonymous>)
    at e.kml (kml.js:316)
    at Object.KML (index.es.js:32035)
    at setTimeout.format (index.es.js:32063)
    at index.es.js:32225

This error does not occur when running locally in development, and when using your online tool, again there is no problems. Therefore we think the issue lies in the minified build.

Just to clarify, KML files without the StyleMap element do not have this problem.

I'd appreciate any assistance you could provide :)

Using as below:

  import * as toGeoJSON from '@tmcw/togeojson';

  ...

  const dom = (new DOMParser()).parseFromString(kmlString, 'text/xml');
  const parsedGeojson = toGeoJSON.kml(dom);

Hi Tom:

I have just started to really explore the GPX format, so forgive any ignorance on my part.

In doing some research about GeoJSON ↔️ GPX conversion and parsers, it seems like there's not a standardized extension for trackpoint metadata, so you invented the [feature].properties.coordTimes array when you originally wrote this lib for Mapbox. (If any of that's not right, please correct me.)

It looks like there has been discussion about using [feature].properties.coordinateProperties to namespace data associated to coordinates, and that coordTimes maps to coordinateProperties.times.

Most of the discussion I found seems to never converge on consensus. The namespacing makes sense to me. Will you share your current perspective on this, and maybe point me to more information if I missed something official?

kmlToGeoJson() currently depends on an implementation of XMLSerializer (i.e., by way of xml2str()), but the current set of environment checks in kml.js which try to pick an implementation (e.g., dynamically requiring xmldom in Node environments) doesn't work in a web worker context. (Context: web workers don't have access to window.XMLSerializer.)

Before working on a PR, would be great to get some guidance from @tmcw on preferred solutions. Some ideas:

1. Modify kmlToGeoJson() to accept a new arg that optionally overrides xml2str(). Example:

kmlToGeoJson(doc, serializeXml=xml2str) {
  // ...
  for (let k = 0; k < styles.length; k++) {
    const hash = okhash(serializeToString(styles[k])).toString(16); // 👈👈👈 
    styleIndex["#" + styles[k].getAttribute("id")] = hash;
    styleByHash[hash] = styles[k];
  }
  // ...
}

2. Try to dynamically import XMLSerializer from xmldom in a web worker context (similar to how require() is used in a Node env). This might be tricky since dynamic imports via import() are async and everything in kml.js is currently synchronous.

3. Stop serializing/hashing XML (i.e., get rid of xml2str(), per #5). Possible drawback here is that the produced GeoJSON features would no longer have properties.styleHash and properties.styleMapHash--so not exactly a backwards-compatible change.

Thoughts?

city.kml.zip
This kml file has the feature inside the document and folder tags and the conversion does not work. How can i be able to make the conversion?

<Document>
<Folder>
...
</Folder>
</Document>

Conversion error with the tags

Conversion without the tags works but without the styles

While importing the kml,
import { kml } from '@tmcw/togeojson';

I am getting the below error. Any idea what loader it's required? I have been looking it for yesterday, but no luck.

ERROR in ./node_modules/@tmcw/togeojson/dist/togeojson.umd.js 1:366
Module parse failed: Unexpected token (1:366)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.

This is how my webpack rules looks like.

rules: [ { test: /\.(js|jsx)$/, exclude: /node_modules/, use: 'babel-loader' }, { test: /\.(css|scss)$/, use: [envType == 'prod' ? MiniCssExtractPlugin.loader : "style-loader", "css-loader", "sass-loader" ] }, { test: /\.(jpg|jpeg|png|gif|mp3|svg|ico)$/, loader: ['file-loader'] }, { test: /\.(woff(2)?|ttf|eot)(\?v=\d+\.\d+\.\d+)?$/, use: [ { loader: 'file-loader', options: { name: '[name].[ext]', outputPath: 'fonts/' } } ] } ]

Hi Tom, thanks for your ongoing support of this project.

Any chance you'd consider walking back this decision?

I've got a fork of tcx with a couple of small QoL fixes.

Thanks!

I have been playing around with both Google Earth and Google My Maps tools and converting the exported KML files to GeoJSON using this tool.

I noticed when importing from these two sources, the icon-offset property that results from converting to GeoJSON gives just the x and y pixels for the feature of the KML files. The following are taken from the KML files.

Google Earth: <hotSpot x="32" y="1" xunits="pixels" yunits="pixels"/>
Google My Maps: <hotSpot x="32" xunits="pixels" y="64" yunits="insetPixels"/>

Google Earth uses yunits="pixels" whereas Google My Maps uses yunits="insetPixels"

What this means when I convert to GeoJSON is that I have no idea what yunit the icon-offset it is based off of. If I attempt to adjust the offset in my map display using this it will be correct for one source, but completely wrong for the other source.

Are there plans or considerations for being able to get this information through the conversion process?

I forked your online tool so that it used the latest version of this library and that is where you can reproduce what I'm seeing by uploading the KML files I have provided in the ZIP file below.

The fork can be found here: https://observablehq.com/d/96ff9e6b1b6edfb1

Google Placemarks.zip

Thank you and let me know if I can help clarify anything.

I'm trying to convert this file: https://www.nhc.noaa.gov/gis/kml/nhc_active.kml

But the conversion is just returning this Object:

Object {type: "FeatureCollection", features: Array(0)}

Any idea what is wrong and if it can be fixed?

Thanks!

gpx

gpx(node: Document): FeatureCollection<Geometry, GeoJsonProperties>

kml

kml(node: Document): FeatureCollection<Geometry | null, GeoJsonProperties>  // note the null

Which means I need to write 2 more lines of code. Trivial, YES! (But it did break my build).

Hi tom,

if I'm not mistaken at present the only way to import the library into the browser (excluding modules usage) is through importing the whole bundle which ships all three parsers: KML, TCX, & GPX (am I wrong?).

I usually do something like this in my plugins:

<script type="text/javascript">

  import('https://unpkg.com/@tmcw/[email protected]/dist/togeojson.umd.js').then(()=> { /* do stuff */ } );

</script>

In your opinion, in order to avoid downloading unused code, it would also be possible to do such a thing?

<script type="text/javascript">

  import('https://unpkg.com/@tmcw/[email protected]/dist/togeojson.gpx.umd.js').then(()=> { /* GPX stuff */ } );
  import('https://unpkg.com/@tmcw/[email protected]/dist/togeojson.kml.umd.js').then(()=> { /* KML stuff */ } );
  import('https://unpkg.com/@tmcw/[email protected]/dist/togeojson.tcx.umd.js').then(()=> { /* TCX stuff */ } );
  import('https://unpkg.com/@tmcw/[email protected]/dist/togeojson.umd.js').then(()=> { /* KML, TCX, & GPX  stuff */ } );

</script>

I think it's not unusual to work with a single format at a time (or at least one file at a time) and in any case it already seemed to me that this library was quite already well structured to achieve this result.

Have a nice day,
Raruto

PS i saw that you are working on placemark.io, may i ask what will be the new cdn url after version 4.7? (maybe I'm wrong, but I don't think anything has been published on npm for version 5.x or so).

Hi Tom,
I believe that the latest current version (0.0.3) actually present on unpkg lacks of some files (or there are some problems with your package.json configuration).

In particular, I noticed that because i was trying to import it with browserify, but:

var toGeoJSON = require("./node_modules/@tmcw/togeojson/dist/togeojson.js"); // OK: pointing directly to installed file

var toGeoJSON = require("@tmcw/togeojson"); // Throws cannot find module '@tmcw/togeojson'

Have a nice day,
Raruto

This converter seems not to import KML <LinearRing> geometries that are nested directly within a <Placemark> (as opposed to being contained within a <Polygon>). I'm attaching an example kmz from NOAA that uses a <LinearRing> as a bounding box. togeojson and Placemark.io import this kind of ring as a feature with null geometry. Importing as a GeoJSON LineString makes sense to me.

Archive.zip

toGeoJSON should produce a notes array that allows you to see if invalid features have been filtered out. This is a follow-up task to #80

I'm seeing errors when importing the module into an ESM project:

import { kml } from '@tmcw/togeojson';
         ^^^
SyntaxError: Named export 'kml' not found. The requested module '@tmcw/togeojson' is a CommonJS module, which may not support all module.exports as named exports.

But if I use this method:

import toGeoJSON from '@tmcw/togeojson';

I see this error:

export { gpx, gpxGen, kml, kmlGen, kmlWithFolders, tcx, tcxGen };
^^^^^^

SyntaxError: Unexpected token 'export'

So I'm kinda stuck. Any idea what's happening here? Using v5.1.2

Depending on browser support…

Hi,

Just a quick question, if there is a blog post or something I should look at please point me there. I am wondering what indicates that the mapbox version is abandoned? Reason I am asking is that I am deciding what to use and of course I would like something that is not abandoned / will not be abandoned in a year or two...

Thank you!

• J

I run into

          `response.xml is not a function error`

I fix it by use response.responseXML, then it works,

   `<script type="module">
        import { kml } from "https://unpkg.com/@tmcw/togeojson?module";

fetch("https://opendata.arcgis.com/datasets/30400d96c9ef427380ff05dabd09fa2e_26.kml")
  .then(function(response) {
    return response.responseXML;
  })
  .then(function(xml) {
    console.log(kml(xml));
  });

</script>`

Further, I run into other error:

                  `togeojson.es.js?module:541 Uncaught (in promise) TypeError: Cannot read property 'getElementsByTagName' of undefined
at kmlGen (togeojson.es.js?module:541)
at kmlGen.next (<anonymous>)
at Function.from (<anonymous>)
at kml (togeojson.es.js?module:577)
at kml_to_geojson.html:9`

Thank you for working to support folders. Would you consider adding another conversion option that includes the folder data in a geojson file along with the style and other data you already include? This would be very helpful. There's an approach that will do this by numbering the folder levels and making them geojson properties. The first folder encountered would be "folder0". If it has a description with it that would be "description0". The description numbers would always match the folder number they accompany in the KML. In the rare case that there is a folder with no placemarks in it, the folder name and description would be ignored.

Below is an example of what this conversion process would look like. It would help to treat the file name as the first folder entry if multiple converted KMLs are later combined, so that's what I've done. KMLs can include other KMLs which results in the tag being used. But like the tag, it can be treated as another folder. A folderpath property would also be helpful.

Point in KML

<Document>
<name>Bob's_Canada_Map.kml</name>
<Folder>
  <name>Canada_Map</name>
  <Document id="root_doc">
    <name>Alberta</name>
    <Folder>
      <name>Calgary</name>
      <description>Largest city in Alberta</description>
      <Folder>
        <name>Architecture</name>
        <Placemark>
          <name>Shops</name>
          <description>Scotia Centre</description>
          <Point>
            <coordinates>-114.0661567,51.0460943,0</coordinates>
          </Point>
        </Placemark>

Point in geojson

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -114.0661567,
                    51.0460943,
                    0
                ]
            },
            "properties": {
                "name": "Shops",
                "description": "Scotia Centre",
                "folderpath": "Bob's_Canada_Map.kml/Canada_Map/Alberta/Calgary/Architecture",
                "folder0": "Bob's_Canada_Map.kml",
                "folder1": "Canada_Map",
                "folder2": "Alberta",
                "folder3": "Calgary",
                "description3": "Largest city in Alberta",
                "folder4": " Architecture"
            }
        },