search

OpenGeoLabs / shapefilemustdie

Page reasoning, why ESRI Shapefile must die
83 stars 24 forks source link

Remove KML #8

Open kannes opened 6 years ago

kannes commented 6 years ago

The text already says that KML has had its heyday. I see no point in recommending a limited, useless format like it?

jachym commented 6 years ago

Same as geodatabase - let's move it to some separate section?

Same actually applies for CSV - it's just one of the formats mentioned, which sometimes occurs on some occasions.

jyutzler commented 6 years ago

I personally believe that relegating KML to the bottom of the page is reasonable. How about you @kannes?

kannes commented 6 years ago

I argue that no-one in their right mind should bother to switch from Shapefiles to KML. :}

jachym commented 6 years ago

well, same applies to CSV, right?

But using same logic, is geojson and gml relevant too?

jyutzler commented 6 years ago

GeoJSON has a legitimate use in the market. I would recommend it over Shapefiles in any sort of web service environment or anywhere that you have a modest amount of data and don't really need indexing.

GML is a different case, but invariably people who need its capabilities already know about it and are using it. I wouldn't recommend for someone to switch from Shape to GML. It is sort of like switching from a horse-and-buggy to a tank. I guess in this analogy GeoJSON is more like a bicycle and GeoPackage is more like a car.

edips commented 5 years ago

I think text based formats like GML, KML, GeoJSON are slow compared to SHP when importing - exporting - processing them with big data. But i think it depends on design of algorithms of GIS softwares or libraries.