Closed scw closed 10 years ago
.lyr files encode style rules, not data itself, so not sure if it's really relevant here (there isn't a section mentioning open styling alternatives, and presumably this is primarily about data, not data plus presentation)
Okay, removed.
FileGDB has a freely available API and works easily with GDAL/OGR, so I don't think its accurate to claim they are only supported "by expensive Esri products".
It's a closed-source, proprietary API with no specification for the format, and the format is intentionally encrypted and obfuscated. I don't see any reason to change this statement.
Yes, the API is closed-source and proprietary, and it doesn't make sense in a current state to recommend it for "simple open data". That said, it is widely used by folks within the open source ecosystem, generally based on its availability in GDAL, so I think claiming that its use is limited to Esri products is factually incorrect.
The format also isn't encrypted, but fair enough to say its obfuscated -- it lacks an open specification, though there is a solid attempt at one.
Since the 'Availability in GDAL' requires an Esri product - the closed-source SDK - no: it's only compatible with Esri products.
To be clear: yes, there is some opinion and emotion involved in this decision. Esri's approach with FileGDB, EsriJSON, zLas, .lyr, and GeoServices REST is offensive to open source developers, myself included. I'm ready to change my mind as soon as the facts change: when open specifications and code are released, but until then Esri's approach to data formats is actively harming open data.
Fair enough. Thank you for your candor.
In particular, I'm excited for the ArcGIS Open Data portal - from what I've seen, it'll serve GeoJSON and common formats, and generally "do the right thing," which will be a huge boon for interoperability.
.lyr
files encode style rules, not data itself, so not sure if it's really relevant here (there isn't a section mentioning open styling alternatives, and presumably this is primarily about data, not data plus presentation).FileGDB has a freely available API and works easily with GDAL/OGR, so I don't think its accurate to claim they are only supported "by expensive Esri products".
There isn't a section about LAS right now -- I think that'd be a good section to add, and I'd include information about the base LAS spec which is interoperable between many (all?) implementations. Mentioning that
.zlas
isn't interoperable seems fine, but it should be contextualized to tell someone what they should be doing, and what data formats are best for interchange of point cloud data.