Hello,
I think will be able to continue developments in the beginning of
February.
I retain all this points to do some changes or discuss if they cause a
problem :
1) Should provide Features through some kind of stream (not to be confused
with InputStream) or iterator.
2) Shapefile should extend DataStore (the proposed common base class for all
formats).
3) MappedByteBuffer too heavy for Shapefile needs (it also complicate the
task of extending DataStore).
4) Avoid shapefile-specific API (e.g. ShapeTypeEnum) if something more
generic is defined by other standards.
5) Codes which, I guess, are still in a draft stage since they ignore
implementation concerns (e.g. AbstractDbase3ByteReader.toCodePage
rebuilding the same relatively large HashMap everytime the method is
invoked). I presume that this is temporary while the work is in process.
6) Policy regarding logging, internationalization and formatting which are
different than the rest of SIS. I think that some agreement would be nice in
order to provide a consistent library.
Regards,
Marc.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Wednesday, January 21, 2015 12:38 AM
To: [email protected]
Subject: Re: Do we create a release candidate this week?
Hello Adam
Le 21/01/15 00:08, Adam Estrada a écrit :
I think it would be great to see another format make it in to the next
release and it looks like the shapefile reader is in disarray. This
means that WKT is the next most logical implementation. What is the
state of Marc's stuff?
As I see, the blocker issue for releasing Shapefile now is its public API:
* Shapefile should extend DataStore (the proposed common base class
for all formats).
* Should produce ISO 19115 metadata at least for the geographic
bounding box.
* Should provide Features through some kind of stream (not to be
confused with InputStream) or iterator.
* Avoid shapefile-specific API (e.g. ShapeTypeEnum) if something more
generic is defined by other standards.
There is also implementation issues, but they could be deferred to a
next release if doing so will not cause major compatibility breaks for
the users:
* MappedByteBuffer too heavy for Shapefile needs (it also complicate
the task of extending DataStore).
* Codes which, I guess, are still in a draft stage since they ignore
implementation concerns (e.g. AbstractDbase3ByteReader.toCodePage
rebuilding the same relatively large HashMap everytime the method is
invoked). I presume that this is temporary while the work is in process.
* Policy regarding logging, internationalization and formatting which
are different than the rest of SIS. I think that some agreement
would be nice in order to provide a consistent library.
But we could delay SIS release in order to provide more attractive new
features. I'm fine with either options (release without new format or
delay).
Martin
