Martin and Travis,

It is true that the Shapefile is very widely used but it has lots and lots
of limitations. The main one that I can think of is that it can't handle
UTF-encoded characters in the attribute table. Can I suggest maybe working
towards something like an "interchange" module where all the file formats
live? For vector data, there are quite a few of them out there. OGR
references many of them [1] but that opens the debate on whether or not to
just use GDAL. I suppose we could just have GDAL support as a module which
would require some sort of JNI bindings to work in a pure Java library like
SIS. What are your thoughts on this?

Adam


[1] http://www.gdal.org/ogr/ogr_formats.html


On Sun, Aug 25, 2013 at 12:43 PM, Martin Desruisseaux <
[email protected]> wrote:

> Hello Travis
>
> Thanks for the update.
>
> Le 25/08/13 18:26, Travis L Pinney a écrit :
>
>  The last thing needed is to switch to the new DefaultFeature in
>> sis-feature. I am not sure how to import this currently. Any ideas on
>> doing
>> this?
>>
>
> Just adding a dependency in the pom.xml should work:
>
>     <dependency>
>       <groupId>org.apache.sis.core</**groupId>
>       <artifactId>sis-feature</**artifactId>
>       <version>${project.version}</**version>
>     </dependency>
>
> The API is currently identical to the original class on the Shapefile
> branch, if I remember correctly. I hope to start working on Feature next
> week, but it should not prevent us from porting Shapefile to the trunk in
> parallel.
>
> Given that I presume that Shapefile will be a very widely used format, I
> wonder if we should port it straight to the "sis-storage" module, without
> creating a "sis-shapefile" module on trunk? The intend is to keep the
> amount of modules reasonably low, with a "core" part and some extensions.
> It seems to me that Shapefile could be part of "core". What do you think?
>
>     Martin
>
>

Reply via email to