-
Notifications
You must be signed in to change notification settings - Fork 24
/
index.html
645 lines (590 loc) · 29.9 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Shapefile must die!</title>
<meta name="description" content="Page explaining why Esri Shapefile is a flawed format and that other alternatives should be used.">
<meta name="author" content="Jachym Cepicky - OpenGeoLabs.cz">
<meta name="keywords" content="gis,#g,shapefile,ESRI Shapefile,bad,get rid of,die">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link rel="shortcut icon" href="images/icon.ico" type="image/x-icon">
<link rel="stylesheet" href="css/styles.css?v=1.0">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta/css/bootstrap.min.css" integrity="sha384-/Y6pD6FV/Vv2HJnA6t+vslU6fwYXjCFtcEpHbNJ0lyAFsXTsjBbfaDjzALeQsN6M" crossorigin="anonymous">
<!--[if lt IE 9]>
<script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<a href="https://github.com/opengeolabs/shapefilemustdie"><img style="position: absolute; top: 0; right: 0; border: 0;" src="https://camo.githubusercontent.com/38ef81f8aca64bb9a64448d0d70f1308ef5341ab/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f6461726b626c75655f3132313632312e706e67" alt="Fork me on GitHub" data-canonical-src="https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png"></a>
<div class="container">
<h1>Switch from Shapefile</h1>
<img class="format-logo img-thumbnail" src="images/ban-shapefile.png" />
<p class="lead">
<a href="https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf">ESRI
Shapefile</a> is a <a
href="https://en.wikipedia.org/wiki/Shapefile">file format for
storing geospatial vector data</a>. It has been around since the early
1990s and is still the most commonly used vector data exchange format.
</p>
<p>While Shapefiles have enabled many successful activities over the years, they also
have a number of limitations that complicate software development and reduce efficiency.
</p>
<p>
We, members of the geospatial IT industry, believe that it is time to stop using Shapefiles
as the primary vector data exchange format and to replace them with a format that takes
advantage of the huge advances that have been made since Shapefile was introduced.
</p>
<p><strong>Read more:</strong></p>
<ul>
<li><a href="#thegoodside">The good side</a></li>
<li><a href="#shapefileisbad">Shapefile is a bad format</a></li>
<li><a href="#alternatives">Shapefile alternatives</a></li>
</ul>
<hr>
<a name="thegoodside"></a>
<h2>The good side</h2>
<p>
Shapefile does a lot of things right.
Here are some reasons why Shapefile is so heavily used:
</p>
<ul>
<li>Shapefile is by far the most widely supported format in existing software packages.</li>
<li>While the format is proprietary, the
<a href="http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf">specification is open</a>.</li>
<li>For many use cases, it is <em>good enough</em>.
<ul>
<li>Its index file (*.shx) contains the offset and length of each feature in the main file (*.shp) which enables good reading performance.</li>
<li>It is relatively efficient in terms of file size. The resulting file, even
un-zipped, is relatively small compared to some other (mostly
text-based) formats.
</li>
</ul>
</li>
</ul>
<div class="alert alert-danger" role="alert">
<a name="shapefileisbad"></a>
<h2 class="alert-heading">Shapefile is a bad format</h2>
<p>Why is Shapefile so bad? Here are several reasons why the Shapefile is a
bad format and you should avoid its usage:</p>
<ul>
<li><a href="#nocrs">No coordinate reference system definition</a>.</li>
<li><a href="#multifile">It's a multifile format</a>.</li>
<li><a href="#10characters">Attribute names are limited to 10
characters</a>.</li>
<li><a href="#255attributes">Only 255 attributes</a>. The DBF file does
not allow you to store more then 255 attribute fields.</li>
<li><a href="#datatypes">Limited data types</a>. Data types are limited
to float, integer, date and text with a maximum 254
characters.</li>
<li><a href="#characterset">Unknown character set</a>. There is no way
to specify the character set used in the database.</li>
<li><a href="#sizelimit">It's limited to 2GB of file size</a>. Although some
tools are able to surpass this limit, they can never exceed 4GB
of data.</li>
<li><a href="#simplefeature">No topology in the data</a>. There is no
way to describe topological relations in the format.</li>
<li><a href="#mixedgeometry">Single geometry type per file</a>. There is
no way to save mixed geometry features.</li>
<li><a href="#hierarchy">More complicated data structures are impossible
to save</a>. It's a "flat table" format.</li>
<li><a href="#3d">There is no way to store 3D data with textures or
appearances such as material definitions.</a> There is also no way
to store solids or parametric objects.</li>
<li><a href="#projection">Projections definition</a>. They are
incompatible or missing.
</li>
<li><a href="#featuretype">Line and polygon geometry type, single or multipart, cannot be reliably
determined at the layer level</a>, it must be determined at the
individual feature level.</li>
<li><a href="#nonull">There is no NULL value</a>, it is painful for numeric values</li>
<li><a href="#addmore">Add more</a> ...</li>
</ul>
</div>
<div class="alert alert" role="alert">
<a name="nocrs"></a>
<h3>No coordinate reference system definition</h3>
<p>
By default there is no definition of the coordinate reference system
used. You can do it using e.g. <code>.prj</code>, but first: this is not
standard part of the specification and second, there are still some
issues, see <a href="projection">projection issues</a> and <a
href="multifile">multifile format</a> more lower.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="multifile"></a>
<h3>Multifile format</h3>
<p>
The Shapefile format uses <a
href="https://en.wikipedia.org/wiki/Shapefile#Overview">at least 3
files</a> (*.shp, *.dbf, *.shx). Users cannot share just one file; you
must send them all. Users typically zip all the files into one archive
and unzip them on the other end of the distribution chain, but this is
cumbersome and error-prone.
</p>
<p>
In addition, other geospatial software packages routinely add their own
extensions to try to overcome Shapefile limitations. Custom additions
are not supported by other tools and limit interoperability.
</p>
<p>
<strong>NOTE:</strong> 3rd December is considered the <em>International Shapefile day</em>,
because thanks to modular, extensible architecture it can have 12+ sidecar files, 3 of which are mandatory.
</p>
</div>
<div class="alert" role="alert">
<a name="10characters"></a>
<h3>10 Characters attribute names</h3>
<p>
Attribute names are limited to 10 characters max. Longer names
are usually automatically shortened. This leads to abbreviated and/or
cryptic attribute names that are unintuitive to the recipient of the
data.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="255attributes"></a>
<h3>255 attribute fields</h3>
<p>
There can be only 255 attribute fields in the database file. For some
applications this is limiting, especially in combination with the <a
href="#hierarchy">flat table structure</a>.
</p>
</div>
<div class="alert" role="alert">
<a name="datatypes"></a>
<h3>Poor support for attribute data types</h3>
<p>
Float, integer, date and character string data types are supported.
Floating point numbers can be stored as text, but there is no support for big
integers (thus the format is not usable, you have data with big
integer identifiers, such as cadastral maps) and the text is limited to only
254 characters.
</p>
<p>
There is no support for more advanced data fields such as blobs, images
or arrays.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="characterset"></a>
<h3>Unknown character set</h3>
<p>
There is no way to specify the character set used in the database. Many
applications are using the old Windows-* or ISO-* data encodings,
while nowadays we are tending to use UTF-8 more. Still there is no way to specify
this in file header.
</p>
<p>
The support for Unicode characters is also very limited.
</p>
</div>
<div class="alert" role="alert">
<a name="sizelimit"></a>
<h3>2GB Size limit</h3>
<p>
The size of both .shp and .dbf component files cannot exceed 2 GB. <a
href="http://www.gdal.org/drv_shapefile.html">GDAL Shapefile driver</a>
overcomes this limit, but
</p>
<blockquote><p>The Shapefile format explicitly uses 32bit offsets and so cannot go
over 8GB (it actually uses 32bit offsets to 16bit words), but the OGR shapefile
implementation has a limitation of 4GB.
</p>
<p>
For compatibility with other software implementations, it is not recommended to use a file size over 2GB for both .SHP and .DBF files.
</p>
</blockquote>
<p>So 4GB is all you can have in single Shapefile. This sounds enough,
but not for all cases.</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="simplefeature"></a>
<h3>Non-topological format</h3>
<p>
Shapefile is simple-feature format. There is no way to store more
complex geometry relationships.
</p>
</div>
<div class="alert" role="alert">
<a name="mixedgeometry"></a>
<h3>No mixed geometry</h3>
<p>
Each file can be only one of the supported geometry formats (Point,
Line, Polygon and others). Mixed geometry features are not possible.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="hierarchy"></a>
<h3>Flat data structure</h3>
<p>
The data structure is limited to <em>flat</em> tables with no
hierarchies, relations or tree structure.
</p>
</div>
<div class="alert" role="alert">
<a name="3d"></a>
<h3>Very limited 3D support</h3>
<p>
Shapefile can't store material definitions nor textures (images
with texture coordinates). 3D models are stored as a triangle or
polygon soup, with no watertight models or parametric geometries
being supported.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="projection"></a>
<h3>Projection Definition Inconsistencies</h3>
<p>
By default, Shapefile contains no information about coordinate reference
system at all. But some software packages do accept <code>*.prj</code>
files, which may contain CRS description.
</p>
<p>
It uses Esri WKT definitions, which are often incompatible
with standard definitions in EPSG or other sources regarding aspects such
as axis order or unit definitions. Furthermore, they often miss
parameters required for reprojection ("Missing Bursa Wolf
Parameters", anyone?)
</p>
</div>
<div class="alert" role="alert">
<a name="featuretype"></a>
<h3>Multi part features has to be defined per-feature</h3>
<p>
Line and polygon geometry type, single or multipart, cannot be reliably
determined at the layer level, it must be determined at the
individual feature level. This leads to incositancy during automatic data processing, you can not relay on input geometry type and test each feature, whether it is single geometry or multiple geometries.
</p>
</div>
<div class="alert" role="alert">
<a name="nonull"></a>
<h3>There is no NULL value</h3>
<p>
There is no way to mark no data in a field of the attribute table.
You cannot distingues zero and no data for numerical fields.</p>
</div>
<div class="alert" role="alert">
<a name="addmore"></a>
<h3>Know about another issue? Send us more!</h3>
<p>
Do you know about more limits or do you want to extend existing ones?
Please do so via pull-request or comment in <a
href="https://github.com/OpenGeoLabs/shapefilemustdie">the
repository</a>.
</p>
</div>
<hr>
<a name="alternatives"></a>
<h2>Alternatives</h2>
<img class="format-logo img-thumbnail" src="images/prefer-geopackage.png"/>
<p>
What are the alternatives to the Shapefile format? To be honest, no alternative
format has overthrown the Shapefile hegemony yet. Some formats nearly
took over (KML, GML, GeoJSON), but their usage was limited to relatively
narrow use cases only.
</p>
<p>
Although there are <a href="http://www.gdal.org/ogr_formats.html">more then
80 vector data formats in use</a> out there, only a few can be
considered as candidates for Shapefile replacement. Please note, that we do
take only <em>open</em> (preferably community) formats into account.
</p>
<strong>List of some Shapefile alternatives</strong>
<ul>
<li><strong><a href="#geopackage">OGC GeoPackage</a></strong></li>
<li><strong><a href="#flatgeobuf">FlatGeobuf</a></strong></li>
<li><strong><a href="#geojson">GeoJSON</a></strong></li>
<li><a href="#gml">OGC GML</a></li>
<li><a href="#spatialite">SpatiaLite</a></li>
<li><a href="#csv">CSV</a></li>
<li><a href="#kml">OGC KML</a></li>
</ul>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr"><a href="https://t.co/6JZZRiP8q5">https://t.co/6JZZRiP8q5</a> featuring two formats as <a href="https://twitter.com/shapefile?ref_src=twsrc%5Etfw">@shapefile</a> replacement. Which do you prefer? <a href="https://twitter.com/hashtag/switchfromshapefile?src=hash&ref_src=twsrc%5Etfw">#switchfromshapefile</a> <a href="https://twitter.com/hashtag/geojson?src=hash&ref_src=twsrc%5Etfw">#geojson</a> vs. <a href="https://twitter.com/hashtag/geopackage?src=hash&ref_src=twsrc%5Etfw">#geopackage</a></p>— Jachym Cepicky (@jachymc) <a href="https://twitter.com/jachymc/status/915950627196456965?ref_src=twsrc%5Etfw">October 5, 2017</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<hr>
<div class="alert alert-success" role="alert">
<a name="geopackage"></a>
<h3>OGC GeoPackage</h3>
<img class="format-logo img-thumbnail" src="images/geopkg.png"/>
<p class="lead">
<a href="http://geopackage.org">OGC GeoPackage</a> is one of the most
promising formats, designed for today's modern applications. GeoPackage is
published as standard by the <a href="http://opengeospatial.org/standards/geopackage">Open
Geospatial Consortium</a>.
</p>
<h4>Features</h4>
<ul>
<li>SQLite as backend</li>
<li>File based, single file</li>
<li>Vectors, rasters</li>
<li>Official extensions</li>
<li>Supported in many software packages</li>
</ul>
<h4>Description</h4>
<p>
GeoPackage is an open, standards-based, platform-independent, portable,
self-describing, compact format for transferring geospatial information.
</p>
<p>
The GeoPackage Encoding Standard describes a set of conventions for storing
the following within an SQLite database:
</p>
<ul>
<li>vector features</li>
<li>tile matrix sets of imagery and raster maps at various scales</li>
<li>attributes (non-spatial data)</li>
<li>extensions</li>
</ul>
<p>
There are several published <a href="http://www.geopackage.org/extensions.html">extensions</a>
for GeoPackage which make this format even more powerful.
</p>
<p>
GeoPackage is now (2017) <a href="https://twitter.com/pvangenuchten/status/914583535465435138">supported in most GIS software packages</a>.
</p>
<p>One downside to GeoPackage is that the underlying SQLite database
is a complex binary format that is not suitable for streaming.
It either must be written to the local file system or accessed
through an intermediary service.
</p>
<p>We recommend GeoPackage as a Shapefile replacement for
scenarios where the recipient will want to query or edit the
data locally.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="flatgeobuf"></a>
<h3>FlatGeobuf</h3>
<img class="format-logo img-thumbnail" style="width:100px;" src="https://flatgeobuf.org/logo.svg"/>
<p class="lead">
<a href="https://flatgeobuf.org/">FlatGeobuf</a> is a new format, designed for performance and simplicity.
</p>
<h4>Features</h4>
<ul>
<li>Binary encoding based on <a href="http://google.github.io/flatbuffers/">FlatBuffers</a></li>
<li>File based, single file</li>
<li>Vectors</li>
<li>Can be efficently serialized and streamed (read/write)</li>
</ul>
<h4>Description</h4>
<p>
FlatGeobuf is an open, standards-based, platform-independent, portable, self-describing, performant and compact format for transferring geospatial information.
</p>
<p>
FlatGeobuf is currently (2020) supported in GDAL 3.1 and QGIS 3.16</a>.
Reference TypeScript/JavaScript implementation is available and suitable for use in for example <a href="https://flatgeobuf.org/examples/openlayers">OpenLayers</a> and <a href="https://flatgeobuf.org/examples/leaflet">Leaflet</a>.
</p>
<p>We recommend FlatGeobuf as a Shapefile replacement for
scenarios where performance is critical and system to system integrations.
Because of the streaming capabilities it is also suitable as an alternative WFS output format
and is available as an official <a href="https://docs.geoserver.org/latest/en/user/community/flatgeobuf/index.html">extension to GeoServer</a>.
</p>
</div>
<div class="alert" role="alert">
<a name="geojson"></a>
<h3>GeoJSON</h3>
<img class="format-logo img-thumbnail" src="images/geojsonicon_400x400.png"/>
<p class="lead">
<blockquote>"GeoJSON isn't a shapefile replacement."<br/>
-- Sean Gillies</blockquote>
<a href="http://geojson.org">GeoJSON</a> is a community format based on the
popular <a href="http://json.org">JSON</a> data exchange format.
</p>
<h4>Features</h4>
<ul>
<li>JSON format</li>
<li>File based</li>
<li>Can handle complex data</li>
<li>File size grows fast</li>
<li>IETF Standard</li>
</ul>
<h4>Description</h4>
<p>GeoJSON is very simple, human-readable, text-based format. Although it
is technically possible to use it with more coordinate reference
systems, the <a href="https://tools.ietf.org/html/rfc7946#section-4">specification
states clearly</a>, that WGS84 is the only system, which
should be used. It can handle complex vector data
features and build complex hierarchical data models.
</p>
<p>Since GeoJSON is a JSON encoding it is very easy to parse.
It also supports streaming (features are dealt with as they come in without waiting for the whole file to load).</p>
<p>
The problem with GeoJSON is that not all geometries can be represented and advanced coordinate reference systems are not well supported.</p>
<p>We recommend GeoJSON as a Shapefile replacement for data interchange particularly for web services. For datasets with
geometries or coordinate reference systems not representable in GeoJSON, GML may be suitable.
</p>
</div>
<div class="alert alert-secondary">
<a name="gml"></a>
<h3>OGC GML</h3>
<img class="format-logo img-thumbnail" src="images/gml-sticker-tag-open.jpg"/>
<p class="lead">
Another <a href="http://opengeoslatial.org/standard/gml">OGC Standard</a>.
</p>
<h4>Features</h4>
<ul>
<li>XML Based</li>
<li>Only vectors</li>
<li>Hierarchies</li>
<li>Thanks to INSPIRE, at least partial support in many software packages</li>
</ul>
<h4>Description</h4>
<p>
GML was picked as the main distribution vector data format the European
INSPIRE initiative. It's a very complex format, and its direct usage in
GIS software is limited. Its main use is as a data exchange format that needs to be
ingested into the user's system (e.g. into a database) to be fully usable.
</p>
<p>
GML is currently often used for open data datasets, since it is
technology-neutral and a supported OGC Standard.
</p>
<p>A major downside to GML is that it is an <a href="http://erouault.blogspot.com/2014/04/gml-madness.html">insanely complex standard</a>.
Few software packages support the entire standard and support for individual parts of the standard varies widely.</p>
<p>
We believe that GML is a candidate for Shapefile
replacement for data interchange in situations where data is too complex to be represented by GeoJSON.
However, for the vast majority of datasets GML is overkill.
</p>
</div>
<div class="alert" role="alert">
<a name="spatialite"></a>
<h3>SpatiaLite</h3>
<img class="format-logo img-thumbnail" src="images/spatialite-logo.png"/>
<p class="lead">
<a href="https://www.gaia-gis.it/fossil/libspatialite/home">SpatiaLite</a>
is popular database, file based data storage.
</p>
<h4>Features</h4>
<ul>
<li>File based</li>
<li>SQL database</li>
<li>OGC Simple Features</li>
</ul>
<h4>Description</h4>
<p>
SpatiaLite is an open source library intended to extend the SQLite core
to support fully fledged Spatial SQL capabilities.
SQLite is intrinsically simple and lightweight:
</p>
<ul>
<li>a single lightweight library implementing the full SQL engine</li>
<li>standard SQL implementation: almost complete SQL-92</li>
<li>a whole database simply corresponds to a single monolithic file
(no size limits)</li>
<li>any DB-file can be safely exchanged across different platforms,
because the internal architecture is universally
portable</li>
</p>
<p>
Support for SpatiaLite is relatively limited and most software
that supports SpatiaLite also supports <a
href="#geopackage">GeoPackage</a> as well. They build on top of
the same underlying technology, SQLite.
</p>
SpatialLite lacks the support for extensions or raster data
present in GeoPackage. While these are not necessarily must-have
features, they may be useful. Like GeoPackage, it is unsuitable
for streaming.
</p>
<p>
Since SpatiaLite offers no clear advantages over GeoPackage at
this time, it should only be considered as a Shapefile
replacement in niche scenarios.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="csv"></a>
<h3>CSV</h3>
<img class="format-logo img-thumbnail" src="images/csv.png"/>
<p class="lead">
Some people tend to use <a href="https://www.ietf.org/rfc/rfc4180.txt">comma
separated files</a> for storing geospatial data.
</p>
<h4>Features</h4>
<ul>
<li>Simple</li>
</ul>
<h4>Description</h4>
<p>
Among non-geospatial people, CSV is very popular, but for most
geospatial applications it is not an ideal format.
</p>
<p>
At least two reasons for not using CSV as Shapefile replacement: It isn't
standardized (there are many dialects out there) and support for non-point
geospatial data is complicated.
</p>
</div>
<div class="alert" role="alert">
<a name="kml"></a>
<h3>OGC KML</h3>
<img class="format-logo img-thumbnail" src="images/kml.png"/>
<p class="lead">
<a href="http://opengeospatial.org/standards/kml">OGC KML</a> was a popular
popular vector data format due to the popularity of Google Earth.
</p>
<h4>Features</h4>
<ul>
<li>file-based</li>
<li>XML</li>
<li>Combines geometry along with cartography</li>
<li>Supports just the WGS-84 coordinate system</li>
</ul>
<h4>Description</h4>
<p>
KML was originally devised as the exchange format for a software package called
Keyhole. When Google purchased Keyhole and released it as Google Earth, KML
gained in popularity. However, as the geospatial community hit the limits of
both Google Earth and KML, KML's popularity has waned. Since it is XML based, it is not efficient
for storing larger datasets. It combines cartography along with the data geometry in one
file, which is problematic when the data has the potential to be used in multiple
ways. Since it officially supports only the WGS-84 coordinate reference system,
it is not suitable for a number of applications.
</p>
</div>
<div class="alert alert-secondary" role="alert">
<a name="geodatabase"></a>
<h3>ESRI GeoDatabase</h3>
<p class="lead">
At its most basic level, an
<a href="http://desktop.arcgis.com/en/arcmap/10.3/manage-data/geodatabases/what-is-a-geodatabase.htm">ArcGIS geodatabase</a> is a collection of geographic
datasets of various types held in a common file system folder, a Microsoft
Access database, or a multiuser relational DBMS (such as Oracle, Microsoft
SQL Server, PostgreSQL, Informix, or IBM DB2).
</p>
<h4>Features</h4>
<ul>
<li>native data structure for ArcGIS</li>
<li>file-based (or database based)</li>
<li>complex data models</li>
<li>proprietary, closed format</li>
</ul>
<h4>Description</h4>
<p>
GeoDatabase is very often used in the ArcGIS environment as the main
exchange data format. Its features are very complex and advanced.
</p>
<p>
On the other hand, since it is a proprietary closed format, implementations
outside the environment of ESRI products are extremely limited. It is only a
candidate for replacing Shapefiles in an enviroment centered on ArcGIS.
</p>
</div>
<hr>
<p>
Last modification: 2017-10-08<br/>
Initially created by: <a href="https://github.com/jachym/">Jachym Cepicky</a>,
<a href="http://opengeolabs.cz/en/home">OpenGeoLabs s.r.o.</a><br/>
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">
<img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a>
<br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a><br />
Contribute: <a href="https://github.com/opengeolabs/shapefilemustdie">On GitHub</a>
</p>
</div>
<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js" integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.11.0/umd/popper.min.js" integrity="sha384-b/U6ypiBEHpOf/4+1nzFpr53nxSS+GLCkfwBdFNTxtclqqenISfwAzpKaMNFNmj4" crossorigin="anonymous"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta/js/bootstrap.min.js" integrity="sha384-h0AbiXch4ZDo7tp9hKZ4TsHbi047NrKGLO3SEJAg45jXxnGIfYzk4Si90RDIqNm1" crossorigin="anonymous"></script>
</body>
</html>