I would not really call it a "standard". The one that does ship with the
core of the library is unmaintained, and the second generation of it is
an extension.
Jody Garnett wrote:
> Martin just a thought; have you considered using the xml binding
> framework - is the geotools standard after all.
Hi Francisco,
This sounds great!! I would be happy to help you guys in any way that i
can, be it to provide guidance on where to start or to review any
patches. Just let me know.
-Justin
Francisco Gabriel Malbrán wrote:
> Hi Jody
>
> I am currently working with a friend of mine with Geotools
remove spatialdbbox library dependency from h2
--
Key: GEOT-1700
URL: http://jira.codehaus.org/browse/GEOT-1700
Project: GeoTools
Issue Type: Task
Components: data h2
Affects Versions
Hi Martin,
Yes this is a problem. The dependency is transitive from the h2 spatial
database bindings. I have been meaning to make the bindings part of the
module to avoid the extra library dependency. I will create a jira to do so:
http://jira.codehaus.org/browse/GEOT-1700
-Justin
Martin Desr
Jody Garnett wrote:
> This looks to be the one we are using. I noticed that all useful
> implemenations extend:
> - AbstractGridCoverage2DReader
>
> So I will add the methods here.
>
Ended up with:
- getInfo(): ServiceInfo
- getInfo( String subname ): ResourceInfo
I have added a default implem
Hi,
FYI,
A bunch of these issues were dealt with in the TransactionStateDiff.
It had these problems at one point and have since then been solved.
It is a slightly more complicated problem because it is only the
difference but I'd guess the principals for solving the problem are
about th
Not sure if simone or martin actually looked at this pending change? I
am adding a couple of methods to GridCoverageReader ...
It looks like the following is no longer in use:
- org.geotools.coverage.io.GridCoverageReader (even though it was only
added in 2.4?)
- org.geotools.coverage.io.Exorefe
Sorry that message was ment for the uDig list; which is learning to work
with Gabriel this week :-)
Jody
> It seems that building geotools locally acquires the dependency; it is
> okay to download from one of the mirrors... something like the following.
>
>> > dest="${lib}/xpp3-1.1.3.4.O.jar"
It seems that building geotools locally acquires the dependency; it is
okay to download from one of the mirrors... something like the following.
> dest="${lib}/xpp3-1.1.3.4.O.jar" usetimestamp="true"
> ignoreerrors="true" verbose="true" />
> dest="${lib}/xpp3-1.1.3.4.O.jar" usetimestamp="true"
Dealing with Geospatial Images is the problem you are now solving. No
doubt of that. Images have an additional layer of meaning on top of the
simple "position-value" relationship of a Coverage. :)
I would actually argue for factoring the additional layers of meaning
entirely out of Coverage (bec
Seriously try it out using the example and documentation; it should meet
your needs (and then some). And it would really benifit the rest of our
community - they could then delegate to your xml bindings when parsing
get capabilities documents and so forth.
Remember sun may fold stuff into Java
Martin just a thought; have you considered using the xml binding
framework - is the geotools standard after all. It may not be sun but it
is dependency every downloads.
Jody
-
This SF.net email is sponsored by: Microsoft
De
I have been gradually contacting people on the svn commit list :-)
So far I have been unable to figure out how to contact the following:
- ckl
- seangeo
- jjray
- dledmonds
- shepshep
- rabhranac - may be covered by a TOPP/
- jfc173
- jakefear
- knutejoh
- crotwell
- tnolli - origionally did the i
Just to chime in with something that might be obvious...
- minx,miny,maxx,maxy was standard to me until I started using JTS, then
minx,maxx,miny,maxy had to become "standard".
- rectangles often use minx,miny,width,height which's annoying too
- I see no _real_ reason to change the argument orderi
Jody Garnett a écrit :
> That sounds like a really scary change; all client code would still
> compile but be wrong?
Yes, thats the problem. The best we can do is to produce a deprecation warning
on 2.4.
> So here is a suggestion - making the constructor package visible (so
> client code will bre
Jody Garnett a écrit :
> I cannot afford to be scared off of trunk; and I don't want to cut
> a 2.5.x branch right now
I don't think that it is necessary - If I introduce any incompatibility, I would
consider that as a bug unless the old behavior was erroneous (but I don't think
there is so many
Martin Desruisseaux wrote:
> According a quick search on Google, it seems to me that current argument order
> for GeographicBoundingBoxImpl(double,double,double,double):
>
> http://javadoc.geotools.fr/snapshot/org/geotools/metadata/iso/extent/GeographicBoundingBoxImpl.html#GeographicBoundingBoxImpl
Okay this answered my questions; I was trying to determine if this email
thread was being communication or frustrating
Looks like the answer is a bit of both:
- frustrating to those working with coverages day in and day out
- communication to everyone else
Adrian Custer you are correct that a de
Andrea Aime a écrit :
> I find the current approach confusing me too... I think it comes from
> the JTS Envelopes, that do use the (xmin,xmax,ymin,ymax) order (why, I
> don't know).
Yes maybe... I did a quick google search I found some emails saying that JTS was
about the only one to do that way.
Martin Desruisseaux ha scritto:
> According a quick search on Google, it seems to me that current argument order
> for GeographicBoundingBoxImpl(double,double,double,double):
>
> http://javadoc.geotools.fr/snapshot/org/geotools/metadata/iso/extent/GeographicBoundingBoxImpl.html#GeographicBoundingB
Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER breaks epsg-extension like factories
---
Key: GEOT-1699
URL: http://jira.codehaus.org/browse/GEOT-1699
Project: GeoTools
Issue Typ
According a quick search on Google, it seems to me that current argument order
for GeographicBoundingBoxImpl(double,double,double,double):
http://javadoc.geotools.fr/snapshot/org/geotools/metadata/iso/extent/GeographicBoundingBoxImpl.html#GeographicBoundingBoxImpl(double,%20double,%20double,%20dou
3) Participation in a european geoserver codesprint and in the geoserver
tele-conference doesn't make much sense from the Geomatys side of things
since no one has looked at geoserver in several months and no one is
working on it right now. Perhaps next year.
It wouldn't be exclusively a geoserv
hello,
I'm still working on the editableMap2D and I felt
on a new kind of error when trying to edit or add
a new feature in a indexedShapefileDatastore.
It looks like this error happen on big shapefiles (>5000 features) and not
on small ones.
First time I see this error :
java.io.IOException: Cu
Hey all,
This discussion makes it clear to me, once again, that distributed
coding of complex code in the absence of very complete design documents
is simply stupid. It appears that those of you working on the coverage
part of the Geotools library don't share the same understanding of the
fundamen
no check of connection validity on ConnectionPool
-
Key: GEOT-1698
URL: http://jira.codehaus.org/browse/GEOT-1698
Project: GeoTools
Issue Type: Bug
Components: data jdbc
Affects V
Simone Giannecchini a écrit :
> How would you classify data like GTOPO30 and GTOPO60 which are
> elevation data, 16 bits unsigned where the No Data values is -?
Packed. And I would add that if "no data" values is -, then it can't be
unsigned 16 bits. It is probably signed 16 bits.
The "sa
27 matches
Mail list logo
