<div dir="ltr"><div>Hi,</div><div><br></div>Extending shapefile capabilities: The one reason which might persuade anyone is the still abundant use of shapefiles for dataexchange.<div>Shapefile does seem to play a vital role there. I don't know of anything equally 'tradeable'.<br>
<div>However, an extension would also endanger the interoperability/dataexchange, so little of this would work short of definining a new shapefile variant specification, working title .shp2.</div><div>I can see the outlines, even though I doubt it will be possible to introduce such a thing. The mods would not be that hard, though.</div>
<div><br><div>Deleting: the bit I've implemented quickly for internal use does use the ghost-feature approach, so I agree there. At the end of the session I pack the .dbf; now I'll consider packing the .shp as well to avoid problems with packages that do not read the .shx. Thanks for the advice.</div>
<div><br></div><div>As done now internally, a request for a deleted record returns a null for does not exist, but does not affect the numbering (fid) of the other records/shapes/rows. In the .shx, only the size is set to 0 for a delete, so an undelete is possible.</div>
<div>For the dbf, the only overhead is maintaining a list of deleted record(number)s.</div><div><br></div><div>To properly operate a shapefile-like system in which a delete actually reduces the number of records would require 2 things:</div>
</div><div>1) another definition of the record identifiers (fid as part of the record). This can be done in the shapefile, of course, since the record number is already stored (1-based); it is just never used afaik.</div>
<div>2) maintain a (kind of) .dbx in memory, to index the valid records much in the same way the .shx does. One could store it or build it when reading the .dbf file. A more efficient scheme should be possible.</div><div>
Y</div><div>ou can indeed not throw such a thing at existing shapefiledrivers.</div><div><br></div><div>Just sharing my thoughts here.</div><div><br></div><div>Jan<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Apr 30, 2014 at 4:30 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le mardi 29 avril 2014 19:46:46, Jan Heckman a écrit :<br>
> Hi,<br>
<div class="">> It appears I have to do some homework on ogr's shapefile functions as it<br>
> stands now.<br>
><br>
> 8GB: If interoperability is more of a priority than capacity, that's a<br>
> valid consideration. I've not really needed anything > 4GB so far.<br>
<br>
</div>I'm not sure there's a point in "extending" shapefile capabilities whereas<br>
there are other formats, more capable, that don't have a 32bit offset<br>
limitation.<br>
<div><div class="h5"><br>
><br>
> Delete:<br>
> By delete I mean leaving the information in the file but (shapefile) taking<br>
> it out of the index chain (.shx), and .dbf, marking the record with an<br>
> asterisk in its firs byte.<br>
> As far as arcgis, I did a delete in this way and tried to load it. When I<br>
> do not reduce the record count in the dbf header, arcgis will not load it;<br>
> when I do reduce the record count in the header, arcgis will load the<br>
> shapefile but the attributes will not match the shapes. As a cross-check,<br>
> you can open the .dbf in open office or excel: the delete will be<br>
> recognized.<br>
><br>
> My guess is that arcgis maps the shaperecords to the physical records of<br>
> the dbf only.<br>
><br>
> To allow use of the shapefile in arcgis,  I have to compact the .dbf. The<br>
> shape will then be handled correctly.<br>
><br>
> A recipe to try this out:<br>
> create a new empty point shapefile, load it in arcgis. Using arccatalog to<br>
> create the shapefile, it will have a single ID integer attribute. That's<br>
> the starting point.<br>
> Create 3 points and give them ID's 1 - 3.<br>
> Now to 'delete' the second record using a diskeditor:<br>
> Copy the shapefile. Open the .shx. The .shx has a header and records<br>
> consisting of offset-length pairs. A pair takes 8 bytes. Change the 2nd<br>
> offset to be identical to the last (00000040 -> 0000004E). Diminish the<br>
> filelength indicator in the header (offset 0x18) by 4 (0000003E to<br>
> 0000003A). Copy the file, except the last 8 bytes to the new .shx file.<br>
> DBF: open in editor, change the first byte of the second record (at offset<br>
> 0x48) to an asterisk. The recordcount in the header is at offset 4 (little<br>
> endian).<br>
><br>
> Load in arcgis, will fail.<br>
<br>
</div></div>Yes I'm not surprised at all and I would say that ArcGIS behaviour is sane.<br>
And I guess that OGR would be defeated too if you tried to open such a<br>
shapefile with it.<br>
If you delete record ID 2, you just have to mark the .dbf record with '*'. For<br>
uniqueness purposes, feature 3 should remain feature 3. And feature 2 be a<br>
"ghost feature". That's whay OGR does when you use the DeleteFeature() API. I<br>
don't think it touches the .shx at all. It could possibly change the offset to<br>
be 0 as a marker for invalid, but we don't even do that.<br>
<br>
Otherwise you have to compact both the .dbf and .shx (and possibly .shp for<br>
software not using .shx as Jukka mentionned) to move data.<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</div></div></blockquote></div><br></div>