Thank you for your worthy advice. Our situation seems to be "starting
up a new project".
On Dec 13, 2007 3:01 PM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> pi3orama wrote:
> > We tried to use stable version. But we met some compilation problems
> > (it seems caused by losing of "community" or "mav
[
http://jira.codehaus.org/browse/GEOT-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett reopened GEOT-1620:
> FactoryFinder.getGeometryFactory( null ) fails to find JTS GeometryFactory
> ---
FactoryFinder.getGeometryFactory( null ) fails to find JTS GeometryFactory
--
Key: GEOT-1620
URL: http://jira.codehaus.org/browse/GEOT-1620
Project: GeoTools
Issue Type:
So trunk is now using jts-1.9-RC6 and has had no problems on the
GeoTools side of things.
Here is the code example that prompted the upgrade:
> static Geometry combineIntoOneGeometry( Collection
> geometryCollection ){
> GeometryFactory factory = FactoryFinder.getGeometryFactory( null );
>
>
What about using an empty geometry? That is currently supported in JTS.
On Dec 13, 2007 9:32 AM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Justin Deoliveira ha scritto:
> ...
> > Indeed. My idea would be to subclass each of the geometry types. So
> > creating a class called NullPoint, NullLineStri
So far I have tried the following with Maven 2.0.8 on trunk:
- clean install
- deploy -Dmaven.test.skip=true
x site
- eclipse:eclipse
Is there anything else people care to try out? Or can I upgrade the
developers guide to say Maven 2.0.8 is okay?
Mvn site is failing for me based on clover.licens
Justin Deoliveira ha scritto:
...
> Indeed. My idea would be to subclass each of the geometry types. So
> creating a class called NullPoint, NullLineString, etc... that
> implemented the NullGeometry interface. Then no existing code should run
> into any of the exception cases which arise when some
Jesse had the same request from me last month; how does. JTS.NULL sound
for a Geometry subclass "Null Object" ?
> So... my thought is to create an interface called "NullGeometry" or
> something like that. That way in the encoder bindings i can do an
> instance of check and encode it as an "xlinked
Justin Deoliveira ha scritto:
> Hi all,
>
> I am emailing the list hoping to get some feedback for an idea that i
> have. First a bit of context. I am working on the wfs xlink
> implementation for OWS-5. One of the requirements is to be able to
> "xlink" geometries.
>
> Now... i know the proper w
> What baout using the new feature model userdata instead?
> Anyways, yeah, userdata is available on Feature only so it annoying to
> store attributes related metadata there...
>
THe problem is that i need to do teh check in the GEometryTypeBinding,
which needs a geometry to work. It would be a b
Hi all,
I am emailing the list hoping to get some feedback for an idea that i
have. First a bit of context. I am working on the wfs xlink
implementation for OWS-5. One of the requirements is to be able to
"xlink" geometries.
Now... i know the proper way to do this is with associations in the new
11 matches
Mail list logo
