{{{
<mloskot> We may have to deal with:
<mloskot> - ungroupped placemarks (no containers in KML file)
<mloskot> - grouped in flat structure (no nested containers)
<mloskot> - grouped in tree structure (nested containers: folders and documents)
<mloskot> I believe, all these 3 cases have to be handled differently regarding creation of layers
<mloskot> 1) Layers created according to geometry types
<D|dge> a Placemark is always contained by a Document or Folder
<mloskot> Ah, so 1st and 2nd are the same
<mloskot> I forgot
<mloskot> So, we have 2 cases
<mloskot> flat or tree
<D|dge> yes
<mloskot> The case with tree needs special treatment
<D|dge> right
<mloskot> Let's see:
<mloskot> Case 1: All placemarks are of the same type in Folder 1
<mloskot> Case 2: Folder 1 stores placemarks of type of point and polygon
<mloskot> The 1st one is simple: we have one layer
<mloskot> The 2nd case is complicated
<mloskot> We know that we *have to* group placemarks according type of geometry
<mloskot> But what about folder?
<mloskot> ie. if we have Folder 1 (points and lines), Folder 2 (points and polygons), Folder 3 (points, lines, plolygons)
<D|dge> Folder 1.1 points
<D|dge> Folder 1.2 lines
<D|dge> ...
<D|dge> or "Folder 1 - points" -> points
<D|dge> put the contenttype in the name
<mloskot> Right, that sounds like a good combination of groupping levels
<mloskot> Level 1: geometry type:
<mloskot> Level 2: container
<mloskot> What about nested containers?
<mloskot> Do we extend Level 2 to nested levels
<D|dge> hm
<mloskot> where I consider "nested level" as point in which  we create new layer
<mloskot> ie.
<mloskot> Folder 1
<mloskot> - Folder 1.1
<mloskot> - Folder 1.2
<mloskot> - Folder 1.2.1
<mloskot> - Folder 1.2.1.1
<mloskot> here, we may have to create even 5 layers
<mloskot> :-)
<mloskot> For instance:
<mloskot> layer:
<mloskot> folder_1.shp - all placemarks stored directly under Folder 1
<mloskot> folder_1_1.shp - all placemarks stored directly under Folder 1.1
<mloskot> folder_1_2.shp -  placemarks from  Folder 1.2
<mloskot> etc.
<D|dge> yes
<mloskot> I assume we can have to deal with something like this:
<mloskot> Folder 1
<mloskot> - Placemark 1
<mloskot> - Placemark 2
<mloskot> - Placemark 3
<mloskot> - Folder 1.1
<mloskot> -- Placemark 1
<mloskot> -- Placemark 2
<mloskot> Folder 2
<D|dge> right
<mloskot> etc
<D|dge> Folder 1 -> Germany
<D|dge> Placemark 1 -> Border
<D|dge> Folder 1.1 -> Bavaria
<D|dge> Placemark 1 Border
<D|dge> Placemark 2 -> Cities
<D|dge> that would be 2 Files/Layers
<D|dge> Folder 1 with Name Germany
<D|dge> and Content Border
<D|dge> Folder 1.1 with Name: Germany | Bavaria
<D|dge> and Content Border and Cities
<mloskot> Number of layers = number of geometry types
<mloskot> Number of layers does not depend on number of containers 
<mloskot> but only on number of geom types
<mloskot> Containers only affect groupping scheme
<mloskot> Am I correct?
<D|dge> no
<D|dge> in my example the Borders are Linestrings
<D|dge> but they would be in two Layers
<D|dge> with spliting the geometrie types
<mloskot> ah, you're perfectly right
<D|dge> my example would do:
<mloskot> my mistake
<D|dge> Folder 1.1 with Name: Germany | Bavaria (linestring)
<D|dge> Folder 1.1 with Name: Germany | Bavaria (point)
<D|dge> so it would be three files/layers
<mloskot> roughly, number of layers = N folders  x  N types
}}}