Zijn er pogingen om de shapefile te vervangen?

Onlangs heb ik veel tijd besteed aan het converteren van perfect goede veldnamen zoals "Percentage van burgers van 25 jaar en ouder met een bachelordiploma of hoger" naar dingen als "edbchogtr" om te voldoen aan de DBF-limiet voor de veldnaam van 10 tekens.

In een andere thread ( "Oddities" in de technische specificatie Shapefile ), geospatialpython merkte op dat "Ondanks de gebreken, eigenaardigheden en beperkingen van het shapefile-formaat het hardnekkig blijft bestaan ​​in en rond het gebied van GIS. andere poging om het te vervangen is te opgeblazen geweest voor eenvoudige vectoropslag of te proprietary. "

Deze activiteit in combinatie met de opmerking van Mr. Lawhead vraagt ​​me af:

  • zijn er ooit expliciete pogingen ondernomen om de shapefile te vervangen als het alomtegenwoordige gegevensopslag- en uitwisselingsformaat van GIS?
  • Zijn er kanshebbers?
  • Als er concurrerende indelingen zijn, waarom zijn ze dan mislukt?
  • Heeft Esri geweigerd om hen te steunen, of is het verhaal gewoon een van technologische inertie?
  • Als er geen pogingen zijn geweest ... waarom niet?

Het lijkt erop dat we het onszelf een beetje beter zouden kunnen doen, zowel als GIS-ontwikkelaars en -gebruikers.

66
Zou graag zien dat Python API File Geodatabase (in ieder geval Simple Features) zou lezen/schrijven zonder ArcGIS-licentie - dat zou Open zijn.
toegevoegd de auteur UnkwnTech, de bron
Geodatabase? maar dan heeft de shapefile nooit echte topologie gehad.
toegevoegd de auteur Erik Öjebo, de bron
U kunt geodatabases schrijven en lezen (via API) met behulp van GDAL gdal.org/ogr/drv_filegdb.html met behulp van resources.arcgis.com/content/geodatabases/10.0/ file-gdb-api
toegevoegd de auteur Erik Öjebo, de bron
Shapefiles en persoonlijke geodatabases (een MS Access-tabel) zijn beperkt tot 2 GB. Dat is niet erg veel data in de huidige termen ... dus zou je File Geodatabases aanraden
toegevoegd de auteur Erik Öjebo, de bron
@canisrufus technisch gezien kunt u ook het ArcObjects-stuurprogramma gebruiken gdal.org/ogr/drv_ao.html dat schrijft naar elke door ESRI ondersteunde indeling (zolang u een ESRI-licentie hebt).
toegevoegd de auteur FlySwat, de bron
@PolyGeo jij en alle anderen :)
toegevoegd de auteur FlySwat, de bron
@celenius Van gdal.org/ogr/drv_shapefile.html "Geometry: het Shapefile-formaat maakt expliciet gebruik van 32-bits offsets en kan dus niet meer dan 8 GB overschrijden (het gebruikt in werkelijkheid 32-bits offsets naar woorden van 16 bit) Daarom wordt het niet aangeraden om een ​​bestandsgrootte van meer dan 4 GB te gebruiken Attributen: Het dbf-formaat bevat geen offsets, dus het kan willekeurig groot zijn. " Dus je kunt dbf's hebben die behoorlijk groot zijn, maar je moet voorzichtig zijn met je shp van meer dan 4 GB. Dan speel je met vuur.
toegevoegd de auteur FlySwat, de bron
@RagiYaserBurhum ik snap het. 4 GB slecht, 2 GB goed. Interessant genoeg beperkte de shapefile-grootte de bestandsgrootte die ik kon laden in PostGIS (op Win 32bit). Volledig afzonderlijk probleem, maar het maakte me opletten hoe groot mijn bestand was.
toegevoegd de auteur Rob Thomas, de bron
@Mapperz Weet u zeker dat de bestandslimiet van 2 GB voor shapefiles geldt? Ik heb een aantal shapefiles gemaakt die recent 3GB groot waren en die ik kon openen in ArcMap.
toegevoegd de auteur Rob Thomas, de bron
@Mapperz Anders dan de onlangs uitgebrachte Geodatabase API, zie ik geen hulpmiddelen voor het schrijven van een geodatabase die gratis zijn. Ik denk niet dat dit als vervanging zou kunnen gelden, behalve in het ESRI-gedeelte van de wereld.
toegevoegd de auteur Bobson, de bron
Ah, een belangrijk verschil.
toegevoegd de auteur Bobson, de bron
Oeps, ik zocht deze doc-tabel naar "geodatabase" en lees dat dit niet zo is schrijf persoonlijke geodatabases. Ik heb gemist dat het FileGDBs schrijft.
toegevoegd de auteur Bobson, de bron
Als DBF of SHP groter is dan 2 GB, kunt u op veel systemen problemen tegenkomen. Beyond 4 GB werkt helemaal niet met SHP en ik denk dat DBF hetzelfde probleem zou hebben. In theorie zou het moeten werken, maar in werkelijkheid gebruikt de meeste software ondertekende 32-bits gehele getallen om ze te openen.
toegevoegd de auteur Nate, de bron

7 antwoord

Dit is een onderwerp dat altijd naar voren komt. Ik heb misschien niet het juiste antwoord, maar ik kan je mijn persoonlijke mening geven.

De reden dat ze worden ondersteund, kan worden toegeschreven aan verschillende kenmerken over hen, dus laat ik er een paar noemen.

  • First, there is a spec. I mean, I am in my early thirties and this thing existed since I was a teenager. So it is safe to say that this spec has been around for some time. Of course, there are several other formats that are also published, but the difference about this one is that...

  • It is relatively simple! It is built on top of the DBF Format, which at the time already existed and was widely supported in several platforms/OSs. There were already parsers that could read half of this format (the DBF part), so it made supporting the extra addition easier. You have a geometry? Sure just serialize it and write it. You are done. Contrast this with a coverage! Try to explain to somebody in simple terms what a topology clean does. It is not trivial to write a topologically clean coverage.

  • Most importantly, I think the #1 reason for shapefiles to still be popular is that they are supported in both Open Source and Proprietary systems alike. What GIS do you know that doesn't support shapefiles?!? Unheard of.

Als vervanging horen we van Bestand GeoDatabases en Spatialite . Beide formaten zijn enorm superieur in termen van functionaliteit, flexibiliteit, snelheid, etc. in vergelijking met Shapefiles. Op hun eigen manier hebben ze bepaalde dingen die ze beter maken dan elkaar op verschillende gebieden, maar een vergelijking van spatialite en FileGDB is zeker buiten de reikwijdte van deze vraag.

Denk ik dat een van deze formaten Shapefiles zal vervangen? Niet in hun huidige incarnaties .

Waarom?

Niet vanwege een technisch argument (ik heb wel gezegd dat ze tenslotte superieur waren in dat aspect), maar vanwege iets anders: licensing.

Dus wat zijn hun problemen?

FileGDB:

FileGDB biedt interoperabiliteit via de nieuwe FileGDB API. Desondanks wordt deze API door ESRI aangeboden in binair formaat . Dit is geen specificatie. Nadat ik eerder in het GeoDatabase-team heb gewerkt, kan ik je zeggen dat dit in tegenstelling tot alle aluminiumfolie-hoed-dragende complottheoretici helemaal niet kwaadaardig is. Dit komt doordat de interne onderdelen van de GeoDatabase bij elke release veranderen. Het publiceren van een volledige specificatie zou in feite alle details bevatten over hoe alles verondersteld wordt te worden gehandhaafd en vervolgens zorgvuldig de veranderingen in het formaat documenteren bij elke jaarlijkse uitgave. Het klopt niet. Dus de FileGDB API, ook al is het geen spec, het abstraheert al die kleine veranderingen. En nu kan het platformonafhankelijk worden gebruikt! Let op, dit is een enorme stap voorwaarts! Gezien de conservatieve aard van ESRI is dit zeker een reactie in de goede richting.

En toch maakt binaire ondersteuning niemand in de Open Source-wereld te gelukkig. Hoe profiteer je dan van het porten van wat code om een ​​andere smaak van Linux te zeggen als ESRI het niet ondersteunt. Dat kan niet. Dit is wat Open Source krachtig maakt, en nu kun je hier geen gebruik van maken. Als ESRI stopt met het ondersteunen van Debian, dat is alles. Je bent klaar. En er is niets dat u kunt doen om het te veranderen.

Spatialite:

Spatialite is geweldig omdat het alle gratis functionaliteit van SQLite krijgt. SQLite wordt overal gebruikt. Het is op je Android-telefoon, op je iPhone/iPad, in Firefox, op Google Chrome, op verschillende commerciële ingebedde apparaten - kan voor altijd doorgaan. Om er echt een Geoformat van te maken (en niet alleen om domme boxbewerkingen uit te voeren), moet het gebruikmaken van dezelfde geometriebibliotheek die PostGIS gebruikt: GEOS . Helaas is GEOS gebaseerd op nog een nog betere geometriebibliotheek die bekend staat als JTS . Alle algoritmen in JTS zijn extreem krachtig, dus wat is het probleem?

Well, JTS is licensed as Open Source LGPL, and LGPL is a viral license. JTS is LGPL, means GEOS is LGPL, means spatialite linked statically with GEOS is LGPL. This sucks. Waarom? Without explaining open source licenses too much, I can tell you that, for example, I cannot use spatialite on, say, an iPhone app because that would make my entire app automatically open source (iOS only allows static linking). Any type of GPL license (reasonably) scares the crap out of ESRI, and so they will not touch it with a 10 foot pole. Hence, ArcGIS, the most popular GIS system in the world does not (and will probably never) support spatialite natively. This automatically kills it as a viable format.

En zo gaan we terug naar waardeloze shapefiles die overal worden ondersteund.

Update:

Blijkbaar was mijn antwoord controversieel genoeg dat iemand besloot dat het OK was om de volledige betekenis van mijn antwoord vrij te bewerken en te wijzigen om hun standpunt te bepalen. Doe dat alsjeblieft niet. Als je het niet met me eens bent, is dat helemaal goed, plaats je je mening in een ander antwoord en laat je de gemeenschap beslissen. Ik rolde de bewerkingen terug naar mijn antwoord om de originele betekenis te tonen. Ik voeg deze update toe voor het geval u het bewerkte antwoord leest dat beweerde dat sqlite een uitvoerbaar formaat was.

50
toegevoegd
LGPL is eigenlijk geen virale licentie - het is specifiek ontworpen om dit te voorkomen. Bovendien is Spatialite gelicentieerd onder de MPL tri-licentie ( source ), dit betekent onder andere dingen kunt u de Mozilla Public License kiezen als de best passende licentie en opereren onder zijn (zeer zwakke copyleft) voorwaarden. Minstens leesbaar is dat ESRI geen reden heeft om Spatialite niet te steunen vanwege de licentie - of ze dat zullen doen (gezien het feit dat het concurreert in bijna dezelfde ruimte als FileGDB) is een ander verhaal ...
toegevoegd de auteur ESV, de bron
Maar nogmaals, dit is een betwistbaar punt, omdat Spatialite is gelicentieerd onder een schema met een licentie van een boom ( groups.google.com/forum/?fromgroups#!topic/spatialite-users‌/& hellip; ), zodat u de licentie kunt kiezen die het beste bij u past - MPL staat statische koppeling toe .
toegevoegd de auteur dlinsin, de bron
@Ragi, je mixt met een bibliotheek en porteert het. Natuurlijk zal porting LGPL moeten zijn, omdat dit in wezen een afgeleid werk is. Maar als je het dynamisch koppelt, wordt het niet beschouwd als een afgeleid werk, het is "werk dat de bibliotheek gebruikt" en je mag je licentie behouden ( en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ). Dus zeggen "LGPL is viraal" zonder aanvullende uitleg is niet juist.
toegevoegd de auteur dlinsin, de bron
Het probleem met SQLite/Spatialite is dat het geen indeling is, het is een relationele database-engine met een ruimtelijke bibliotheek erboven. Hoewel het doet wat het heel goed doet, zorgt het ervoor dat de gegevens op de relationele manier worden opgeslagen, wat niet altijd de meest geschikte manier is. Ook maakt de complexiteit van het SQLite-bestandsformaat ( sqlite.org/fileformat2.html ) het moeilijk toegang tot de gegevens zonder de SQLite-engine en is daarom niet geschikt om een ​​open en gemakkelijk toegankelijk bestandsformaat voor gegevensuitwisseling te zijn. Daar was het niet echt voor ontworpen.
toegevoegd de auteur dlinsin, de bron
@Ragi zolang je LGPL-software dynamisch koppelt, is er geen viraliteit
toegevoegd de auteur dlinsin, de bron
@ bugmenot123 Prima, corrigeer het dan als je dat wilt, maar beschuldig me niet van het verspreiden van FUD over OS omdat het beledigend is. Ik schrijf al meer dan een decennium OS-code (ik zou niet verbaasd zijn dat je een deel van mij daadwerkelijk hebt gebruikt) en dat was geen kwade tirade. Het was waar - en dat is het nog steeds. Dynamische koppeling in iOS van LGPL (nou ja, om precies te zijn, frameworks waren toegestaan ​​in iOS 8). Dit is nooit een technisch probleem geweest, maar een juridisch probleem. Distributie in de Appstore vereist code-ondertekening - en helaas voor alle OS-liefhebbers zoals ik - is LGPL hier een fuzzy licentie voor. Geen precedent in de rechtszaal.
toegevoegd de auteur FlySwat, de bron
@igorbrejc Ik denk dat een verduidelijking die ik denk dat ik je verschuldigd ben, is dat ik denk dat spatialite zonder geos of proj vrij nutteloos is. Spatialite zonder onze projecties, intersectie, buffers, correcte resultaten voor een van de clementini-operators, enz. Gebruikt het niet. Op dat moment kun je net zo goed plain sqlite gebruiken zonder spatialite. Voor die opstelling, zeg, op mijn iPhone, is er geen tri-licentie-optie. Het is pure LGPL. Dat is mijn persoonlijke mening. Als je ESRI hebt gevraagd om het te ondersteunen, haalt de kosten-batenanalyse het uit de vergelijking. Voordelen: ondersteuning van OS-indeling die mijn GDBS kan vervangen. Risico: LGPLing ArcMap
toegevoegd de auteur FlySwat, de bron
@ bugmenot123 dus je hebt het over mijn "ranting" uit 2012 wanneer dit waar was? Geef me een breekmaatje. En net zodat u het juiste argument krijgt, had ik het over iOS en LGPL - dit klopt nog steeds en de ondersteuning waar u over spreekt, is voor Desktop waarmee dynamisch linken mogelijk is. Als je gaat kritiseren, weet dan tenminste waar je het over hebt.
toegevoegd de auteur FlySwat, de bron
@IgorBrejc Ik besef dat spatialite meer is dan een formaat. Je kunt hetzelfde echter over FileGDB argumenteren. FileGDB (zoals elke andere GeoDatabase) brengt object relationeel gedrag met verschillende GIS-specifieke concepten: denk aan geometrische netwerken, topologieën, representatieklassen, blikken, kadastrale gegevenssets, enzovoort. In dat opzicht is het zelfs verder weg van shapefiles dan spatialite, maar toch wordt nog steeds (correct) ter sprake gebracht in deze discussie. Vandaar waarom ik spatialiet meeneem.
toegevoegd de auteur FlySwat, de bron
@om_henners Ik aarzelde echt om de virale aard van LGPL in deze context te brengen, omdat ik me realiseer dat sommige mensen zich extreem beledigd voelen als ze de GPL-viral bellen. Ik wil deze draad niet veranderen in een licentieprobleem. Het argument blijft echter. ESRI ondersteunt geen spatialite native omdat het LGPL is en andere platformen die statische koppelingen alleen toestaan, zonder het te gebruiken zonder zichzelf te LGPLen.
toegevoegd de auteur FlySwat, de bron
@om_henners Afgeleide werken omvatten ook het bekijken van de broncode en het maken van een poort. Omdat de originele code in Java is en GEOS in C ++ is, kan ik je vertellen dat dit de reden is waarom GEOS LGPL is. Er is geen weg omheen. Dat is viraal, niet?
toegevoegd de auteur FlySwat, de bron
@IgorBrejc Als u mijn antwoord leest, vindt u een voorbeeld van een geval waarin geen koppeling vereist is en u nog steeds viraliteit krijgt. De poort van Java's JTS naar GEOS in C ++ heeft geen enkele linkage en je moet nog steeds deze licentie als LGPL licentiëren.
toegevoegd de auteur FlySwat, de bron
@IgorBrejc Nog erger, zoals ik in mijn antwoord heb verklaard, bepaalde platforms alleen stellen u in staat om (iOS) statisch te koppelen als een externe ontwikkelaar. Dit maakt het gebruik van LGPL-code in iPhone/iPad slechter dan onhandig.
toegevoegd de auteur FlySwat, de bron
@Igorbrejc spatialite, zonder geos is nog niet half zo handig. Er had een keuze kunnen worden gemaakt om de Boost-geometriebibliotheek te gebruiken in plaats van geos en u had een veel meer permissieve licentie kunnen hebben voor platforms zoals iOS. Maar dat is een afzonderlijke discussie. Mijn antwoord blijft, ESRI zal niets * GPL erop aanraken. Als je de licentiekwesties wilt bespreken die mensen over ruimtelijkite te zien krijgen, moeten we een nieuwe vraag beginnen. Het zou passender zijn.
toegevoegd de auteur FlySwat, de bron
@canisrufus bedankt man! Ik begon te denken dat deze thread veranderde in een licentie die doet denken aan de duizenden BSD versus GPL die er zijn en ik begon spijt te krijgen van het beantwoorden
toegevoegd de auteur FlySwat, de bron
dus iedereen interpreteert het anders. Als je meer wilt begrijpen, kun je de wiki lezen van een van de populairste dual-licence open source frameworks ter wereld (QT) wiki.qt.io/Licensing-talk-about-mobile-platforms Dit is een complex probleem dat simpelweg niet bestaat met Apache, MIT, BSD en andere OS-licenties. Heck, zelfs betwistbaar de meest populaire geometriebibliotheek ter wereld, JTS, maakt momenteel een volledige relicensing-inspanning door de Eclipse LocationTech-groep om, onder andere, die juridische rommel te vermijden voor gebruik en afgeleid werk.
toegevoegd de auteur FlySwat, de bron
@ bugmenot123 trouwens, een aantal van de antwoorden die je op dit forum geeft, zijn afkomstig van open source-projecten die ik sterk bijdraag aan code. U gebruikt mijn OS-code ... u bent welkom :)
toegevoegd de auteur FlySwat, de bron
Ik weet dat dit echt van het origineel is vertraagd, maar als een update voor het geval iemand anders dit vindt: ESRI heeft stil (heel rustig) Spatialite-ondersteuning toegevoegd aan ArcGIS 10.2. Tot dusverre is het gebruik ervan vrij naadloos, maar de databases kunnen alleen in ArcPy worden gemaakt (maar overal worden gebruikt). Het omzetten van tabellen met grote tekstvelden lijkt ook een probleem, maar het is anders werkbaar
toegevoegd de auteur Seremonia, de bron
Volgens dit antwoord , kunt u een LGPL-app statisch koppelen als u ook op verzoek de middelen verstrekt om de applicatie voor iedereen te bouwen dat u uw binaire bestanden hebt gedistribueerd. Dat betekent alle bronnen van LGPL-bibliotheken die u hebt gebruikt en de objecten (maar niet de bron) van uw bedrijfseigen code. U hoeft de bron niet met elk binair bestand te distribueren en u hoeft uw binaire objecten niet openbaar te maken. Alleen beschikbaar voor geïnteresseerde klanten.
toegevoegd de auteur Forseti, de bron
Hey @RagiYaserBurhum, "ESRI ondersteunt geen spatialite native omdat het LGPL is en andere platforms die statische koppelingen alleen toestaan, het niet kunnen gebruiken zonder LGPLing zelf." -> Ze hebben feitelijk zoveel jaren geleden gedaan, middelen. arcgis.com/en/help/main/10.2/index.html#//… Tijd om uw boze tirades te verlichten en FUD te stoppen met verspreiden?
toegevoegd de auteur bugmenot123, de bron
Stack Exchange is geen vluchtig forum, de antwoorden moeten de tand des tijds doorstaan. Je antwoord was toen al borderline en het is vandaag niet bruikbaar. Trouwens, blijkbaar sinds 3 jaar geleden kun je dynamische koppeling op iOS gebruiken: stackoverflow.com/a/4733885/4828720
toegevoegd de auteur bugmenot123, de bron

Het SHP + SHX-deel zelf is niet zo slecht. Het echte probleem ligt in het DBF-gedeelte. Dat zou kunnen met een nieuw formaat, dat unicode en allerlei moderne veldtypen ondersteunde. Het probleem is dat het goed wordt ondersteund door alle software die er is.

18
toegevoegd
Ik heb vaak gepleit voor een Shapefile-wijziging die eenvoudigweg een UTF-8 CSV-bestand voor de DBF heeft vervangen. Het zou eenvoudig zijn om minimale wijzigingen aan bestaande softwarepakketten te ondersteunen en te eisen.
toegevoegd de auteur Robert Höglund, de bron
Integendeel, @Uffe, CSV-bestanden kunnen willekeurig worden benaderd: je hebt alleen een index nodig, net zoals DBF-bestanden dat doen voor efficiënte zoekopdrachten. Het grootste probleem dat ik zie is dat ogenschijnlijk kleine wijzigingen die van nature in CSV-bestanden voorkomen, zoals het citeren van tekenreeksen of CR/LF-conversies, alle byte-offsets zullen verknoeien. De vaste lengte recordstructuur van een DBF-bestand, hoewel minder efficiënt in opslag, heeft dat probleem niet.
toegevoegd de auteur whuber, de bron
@canis Fox Software deed een kleine (eigen) poging in de late jaren '80. Nadat MS ze had gekocht (ca. 1990), was dat dat. De community creëerde een DBF 3-standaard en dat bevroor vrijwel alle ontwikkelingen. MS heeft Access vrijgegeven; FoxPro is uitgestorven; de wereld ging verder.
toegevoegd de auteur whuber, de bron
+1 Het verbeteren van het DBF-gedeelte is ook helemaal niet zo moeilijk: het komt er echt op neer om softwareontwikkelaars ertoe over te halen iets te bereiken.
toegevoegd de auteur whuber, de bron
Is er een poging geweest?
toegevoegd de auteur Bobson, de bron
Dit is een grap, toch? U kunt niet serieus een index voorstellen voor CSV-bestanden.
toegevoegd de auteur Nate, de bron
CSV staat geen willekeurige toegang toe, dus het is niet toegestaan.
toegevoegd de auteur Nate, de bron

At least spatialite has the intention, see eg this presentation http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

Aan de andere kant denk ik dat de belangrijkste reden dat het mislukte is dat shp goed wordt ondersteund door veel applicaties en slechts kleine tekortkomingen heeft.

Anderen delen deze mening ook:

Dit komt niet omdat het SpatiaLite-project ons geen hulpprogramma's heeft gegeven   implementeren, het kan de gemeenschap niet veel schelen. SHP   werkt voor hen en er is geen reden om te veranderen.

http://www.spatiallyadjusted.com/2010/09/16/SpatiaLite-is-not-the-shapefile-van-de-toekomst/

More thoughts on Esri file geodatabase, spatialite and autodesk sdf here: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

7
toegevoegd
Eigenlijk is de licentie voor spatialiet minder dan ideaal - het heeft niets met de tools te maken.
toegevoegd de auteur FlySwat, de bron
@Scro, 3 megabyte is te groot? Het is zeker niet te groot voor de desktop. U moet mobiele apparaten overwegen. Is er ook een andere Spatial API met vergelijkbare functionaliteit in een kleiner formaat dan Spatialite?
toegevoegd de auteur commando, de bron
@klewis - het is niet zo erg per se, het is gewoon erg inefficiënt als je bedenkt dat er heel veel kleine (denk <200kb) datasets zijn. Dat is veel overhead, vooral in het licht van het feit dat je, eenmaal ontvangen, elke dataset normaal in het 3mb-bestand zou achterlaten, of het in een bestaande database zou rollen. Voor de duidelijkheid, ik <3 spatiaLite - maar we hebben het over gegevensoverdracht, waarbij een soort van een plat bestand/xml/wkb veel efficiënter zou zijn.
toegevoegd de auteur user5929, de bron
Zo goed als ik denk dat spatiaLite is, is het ~ 3 megabytes aan overhead in functies, referentiesystemen, enz. Die voorkomen dat het een goed all-round uitwisselingsformaat wordt.
toegevoegd de auteur user5929, de bron

Esri is al verschillende jaren het promoten van File Geodatabases als vervanging voor shapefiles.

Meer recent hebben ze een API geboden die eventuele rariteiten verbergt.

6
toegevoegd
@canis dat je gelijk hebt. Op het moment dat nobody shapefiles zou hebben overgenomen, met uitzondering van het feit dat ESRI ze specifiek promootte als een open GIS-gegevensuitwisselingsformaat. Zelfs met de beperkte softwaretools die op dat moment beschikbaar waren, met de release door ESRI van een duidelijke .shp/.shx-specificatie (en een toezegging om eraan te blijven vasthouden), werd het een kwestie van slechts een paar uur werk om code te schrijven om te lezen en schrijf shapefiles: geen reverse-engineering nodig.
toegevoegd de auteur whuber, de bron
Ik heb niet veel met geodatabases gewerkt. Wikipedia zegt dat ze een "gesloten" standaard zijn, bijvoorbeeld de geodatabase-specificatie is niet gepubliceerd. Het lijkt moeilijk om een ​​zeer brede acceptatie te krijgen zonder de internals van het formaat te publiceren. Hoewel ik te jong ben om de geschiedenis te kennen, denk ik dat shapefiles deels zo populair zijn vanwege het openbare deel van de specificatie. De API lijkt een goede stap.
toegevoegd de auteur Bobson, de bron
Zolang de API een black-box binaire blob is, zal FGDB niet dezelfde acceptatie als SHP zien. Zelfs als Esri al hun klanten ervan overtuigt om vanuit SHP naar FGDB over te schakelen, is de API niet echt compatibel met open source.
toegevoegd de auteur Forseti, de bron

GeoPackage is a promising successor. It's similar to Spatialite but from OGC and it's been adopted by many software, inlcuding ArcGIS and OGR.

Zie de officiële startpagina http://www.geopackage.org/ en b. deze presentatie: http://www.slideshare.net/JeffYutzler/geopackage-swg-overview

6
toegevoegd

Een XML-dialect, zoals GML, is zeker niet geoptimaliseerd om enorme datasets te gebruiken, maar kan worden gebruikt als uitwisselingsformaat tussen software of tussen platforms.

Ik geloof niet dat er een probleem is met de licentieverlening (zie de post van Ragi Yaser Burhum over de virale kenmerken van Spatialite) en het is vrij eenvoudig om bestaande parsers aan te passen indien nodig.

3
toegevoegd
Canisrufus heeft gelijk. Er zijn verschillende problemen met GML. De Infoset kan worden genavigeerd met XPath, maar iedereen die heeft geprobeerd om ruimtelijke indexering bovenop xml te implementeren, zal je vertellen hoe irrationeel dit is en hoe slecht het is gekoppeld aan traditionele relationele databases. Zonder op veel details in te gaan, als iets dat zo basaal is als indexeren en opvragen niet triviaal wordt, is het formaat opgeblazen en moet je de volledige dataset in het geheugen hebben om er iets mee te doen, dan is dit geen goede optie.
toegevoegd de auteur FlySwat, de bron
xml is opgeblazen als het wordt opgeslagen als gewone tekst. Er zijn gratis (zowel gratis als gratis te wijzigen en herdistribueren) beschikbare binaire xml-bibliotheken die kunnen dienen als vervanging van xml-lezers, waardoor mensen de vrijheid hebben om zowel de leesbaarheid van xml als de prestaties en opslagefficiëntie van binaire bestanden te gebruiken. . De enige reden die ik kan bedenken omdat deze nooit op een grote manier wordt opgenomen, is zoals johandvw hierboven vermeldt : nee je geeft erom, .shp is "goed genoeg" geweest zoals het is.
toegevoegd de auteur Greg, de bron
Ik denk dat het niet genoemd is om de reden dat je het opvraagt, dat het niet is geoptimaliseerd voor grote datasets. xml is opgeblazen. De hier genoemde formaten zijn binair, waarbij GML punten opslaat als tekenreeksen. De grootte kan een andere orde van grootte hebben.
toegevoegd de auteur Bobson, de bron

Om hier vanuit een ander perspectief op te komen, weet ik niet zeker of het gebruik ervan is "Percentage van de burgers van 25 jaar of ouder met een bachelordiploma of hoger" is een perfect goede veldnaam. Terwijl het mengen van spaties en apostroffen kan worden afgehandeld, is het waarschijnlijker dat je bugs introduceert als je code of vragen schrijft.

Naar mijn mening moet de toekomst van de verspreiding van ruimtelijke gegevens zich richten op internet en webservices, en de WFS specificatie (die GML gebruikt) is open en vastgesteld. GeoJSON is kleiner en kan eenvoudiger in JavaScript worden gebruikt. Maar met compressie zijn de maten vergelijkbaar.

Ik wil ook graag een stem uitbrengen voor ESRI's Personal geodatabases . Het kan een vaak verguisd Microsoft-formaat zijn, maar het ondersteunt ODBC-, SQL-query's, weergaven en biedt niet-ontwikkelaars de mogelijkheid om gemakkelijke formulieren voor gegevensinvoer te maken en ten minste een niveau van gegevensintegriteitscontroles (gegevenstypen, lengtes, unieke waarden) te omvatten .

1
toegevoegd
Dat is echter echt de rol van de datasets metadata. De shapefile kan een XML-bestand met dezelfde naam gebruiken om dit op te slaan.
toegevoegd de auteur Swinders, de bron
Dat is een geldig punt. Wat goed is aan hen is dat, gegeven de kennis van de Engelse taal, men kan achterhalen wat de velden betekenen.
toegevoegd de auteur Bobson, de bron