feat(parser): parse LineStyle, PolyStyle and SimpleData

[danielebarbaro]

Two gaps that both end the same way: the parser reads the file, reports success, and silently returns nothing for data that is right there in the document.

1. Lines and polygons have no style

getStyles() read IconStyle and LabelStyle and nothing else. Those two describe a point marker. The elements that describe everything not a point were skipped:

• LineStyle — color and width, the stroke of a LineString and the outline of a Polygon
• PolyStyle — color, fill and outline, the fill of a Polygon

So a document full of routes and areas parsed fine and came back with geometry that could not be drawn: no colour, no width, no fill. The information was in the file the whole time.

Both are now parsed.

Only what the document declares

KML defines defaults for all of these (width 1, color ffffffff, fill and outline 1). The parser does not fill them in. Emitting a default would stop the caller telling "the file said nothing about width" apart from "the file said width is exactly 1", and a renderer that wants the default can apply it itself.

<fill>0</fill>

Read with isset(), not a truthiness check:

if (isset($polyStyle->fill)) {
    $parsed['fill'] = (string) $polyStyle->fill === '1';
}

if ($polyStyle->fill) would be false for <fill>0</fill> and the key would vanish — which is precisely the case where the document is saying something non-default and the caller most needs to know. There is a test for it.

2. ExtendedData ignored half the spec

foreach ($placemarkXml->ExtendedData->Data as $data) { ... }

Only <Data> pairs. But KML has a second form, and it is the one ogr2ogr and QGIS emit:

<ExtendedData>
  <SchemaData schemaUrl="#sample">
    <SimpleData name="area">12</SimpleData>
    <SimpleData name="region">Piemonte</SimpleData>
  </SchemaData>
</ExtendedData>

Every attribute in such a file was dropped. getPlacemarks() returned extendedData => [] and toGeoJson() carried nothing into properties. No error, no warning: the data was simply gone.

Both forms now land in the same map. SimpleData is applied last, so if a document somehow declares the same name both ways the explicit schema value wins. Several <SchemaData> blocks in one <ExtendedData> are all read.

Note that <SimpleData> holds its value as the element's own text, not in a <value> child like <Data> does — which is why the existing loop could never have picked it up even by accident.

Tests

tests/StyleDetailsTest.php and tests/ExtendedDataTest.php, 10 tests. 9 of the 10 fail on main; the one that passes is the existing <Data> behaviour, which is deliberately unchanged.

• LineStyle color + width
• PolyStyle color + fill + outline
• an explicit <fill>0</fill> survives as false
• undeclared elements are absent rather than defaulted, and a LineStyle-only style has no polyStyle / iconStyle / labelStyle keys
• IconStyle and LabelStyle still parse exactly as before, alongside the new ones
• SimpleData inside SchemaData
• Data and SimpleData mixed in one ExtendedData
• SimpleData spread across several SchemaData blocks
• extended data reaching GeoJSON properties

Suite goes 39 to 49. Pint and PHPStan clean.

Behaviour change

getStyles() entries can now carry lineStyle and polyStyle keys, and extendedData can now be non-empty where it used to be empty. Additive: nothing that was returned before changed shape. Worth a changelog line so people know the data is there.

Not in scope

<Folder> nesting, NetworkLink, GroundOverlay, TimeStamp/TimeSpan and gx:Track are still unsupported. The README does not yet state which elements are supported at all, which is the next thing worth fixing.