Re: [Geotools-devel] geopackage unsupported module

[Chris Holmes]

Definitely should be unsupported, since the specification itself isn't even
supported. Hopefully by end of September it'll be ratified - I've been
going to most all the meetings, it's come along pretty nicely. And Justin
helped a lot with this early coding of it.




On Wed, Jul 10, 2013 at 5:52 PM, Justin Deoliveira wrote:

>
>
>
> On Wed, Jul 10, 2013 at 3:33 PM, Jody Garnett wrote:
>
>> This is much more exciting then your low key delivery Justin :)
>>
>> So as a supported module we need to do the code review thing, check
>> headers and code coverage, and I need one page of docs ( as small as a
>> single code example you can inline in from a test case ).
>>
>
> I am asking for an unsupported module.
>
>>
>> So what can I do?
>>
>> Vote +1
>> And check the headers once it is in.
>>
>> Can you round up volunteers for doc page and test coverage?
>>
>
> I was under the impression these were things typically worried about when
> one wants to push the module from unsupported into the main library.
>
>>
>> --
>> Jody Garnett
>>
>> On 11/07/2013, at 3:19 AM, Justin Deoliveira 
>> wrote:
>>
>> Hi all,
>>
>> Some folks may have heard of the geopackage spec that is currently being
>> developed by the OGC. For those that haven't the short of it is that it is
>> a SQLite based format capable of housing vector and raster datasets, as
>> well as pre rendered tile sets (inspired by mbtiles).
>>
>> We've been working on an implementation for geotools and would like to
>> push it in as an supported module. The code is currently on a branch in my
>> github repo.
>>
>>   https://github.com/jdeolive/geotools/compare/geopkg
>>
>> Some additional technical information about the implementation.
>>
>> It uses the same xerial sqlite driver we use for the spatialite
>> datastore, although geopackage has no requirement for spatialite so we just
>> use the base driver without any of the spatialite dependencies.
>>
>> For the vector support the module contains a datastore (jdbc based).
>>
>> The raster support is currently somewhat lame. In general i am not sure
>> how useful the raster bits of the geopackage spec will be. It is actually
>> an optional part of the spec but we implemented a rough initial version of
>> it. Basically the format gives back a coverage reader for blobs stored in
>> the database. It currently supports world images and geotiffs.
>>
>> The tile stuff is pretty straight forward and given a tile index the
>> format will give back an image blob stored in the database, or given a
>> range will give back an iterator.
>>
>> For those interested here is the latest version of the spec.
>>
>>
>> https://dl.dropboxusercontent.com/u/1663985/12-128r7_OpenGIS_GeoPackage_Implementation_Specification_accept_changes.pdf
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>> --
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Donay links in Jira

[Chris Holmes]

On Fri, Jun 28, 2013 at 11:00 AM, Andrea Aime
wrote:

> On Fri, Jun 28, 2013 at 3:23 PM, Chris Holmes  wrote:
>
>> Looking at it I think it needs to be as complicated as your questions
>> imply.
>>
>> You don't need to set a target amount. People just post the incentive for
>> what it is worth to them. If no one fixes then no one does.
>>
>
> I can be ok with the rest, but this point seems really weird to me.
> Like, I would never allocate money on a ticket without knowing what the
> total amount needed to solve the issue is?
>
> Do you think the funding for OL3 would have gone well if they did not set
> an expectation beforehand?
>
> Given that every bug fix needs a test, probably a backport to the stable
> series, and if it's not the maintainer doing the work,
> a review, I'd say there is no such a thing like a 100$ fix that people
> could just carelessly put money against.
>
>
Yeah, I'd agree. But I think this system doesn't really support the setting
of amount. I guess I'd just see this thing as a way to start that
conversation, and to get across to people we are open to it. People likely
will use the more normal avenue, just emailing a core developer to ask.
This is just another potential way in. I think if we get a number of people
putting $100 up then we can revisit the process. I'm not convinced than
many people will, but it'd still be an interesting data point to learn from.



> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Donay links in Jira

[Chris Holmes]

Looking at it I think it needs to be as complicated as your questions imply.

You don't need to set a target amount. People just post the incentive for
what it is worth to them. If no one fixes then no one does.

Any developer (even non core committers, though that's unlikely) can then
make a patch for it. Then the money can go to them.

I guess maybe there needs to be one account for the project?

I'm inclined to just leave it there, and then figure out the details if
anyone actually posts an amount that would motivate anyone on the project
to do anything. If they do then we found a new way to get some money in,
and that's great. And we can sort out more details. If no one uses it
that's fine too.

But the company will hold the money in escrow until we set up an account,
so there's no downside I see.


On Fri, Jun 28, 2013 at 8:46 AM, Andrea Aime
wrote:

> Hi,
> sorry for the cross post, the issue is of interest of both community.
>
> Lately Jira got a new "Doney" plugin that allows to make donations
> targeted at a certain issue, e.g.:
> https://jira.codehaus.org/browse/GEOS-5869
> https://jira.codehaus.org/browse/GEOT-4000
>
> Now... as far as I know the projects are not setup to handle donations and
> decide how to assign the money to the actual resolution of issues (how do
> we put a target amount? how do we assign who works on it?)
>
> Imho, we should either organize ourselves to leverage that, or ask
> Codehaus to remove that plugin from our jira sites...
>
> Opinions?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Pull Request Policy

[Chris Holmes]

Ah right, apologies Christian, I'd completely forgotten, I guess because
you've actually been doing great work with it for so long, and you've
expanded your contributions in to many other areas.

Oh yeah, and merging the file and database image modules would be really
great. One preliminary step might just be to upgrade the existing database
imagery stuff to the new API? Since all the databases naturally have their
connection params for a set of coverages. Would also be great to get more
of a GUI on the jdbc image mosiac, so there's less xml configuration files.

In the long term I'd also love to see a bit of a 'merge' with the vector
datastores. So that you'd just fill out your postgis, oracle or arcsde
connections once, and then from there can select the vector and raster
stores that you want to publish. But an interim step is just making it so
you can connect once and select your raster stores to publish, since now we
have to select each one at the store level (I believe that's what the new
coverage api gets us, though correct me if I'm wrong).


On Wed, Jun 26, 2013 at 5:45 AM, Christian Mueller <
christian.muel...@os-solutions.at> wrote:

> Hi
>
> @Chris. I am the long term maintainer of the DB2 module. See the latestet
> release notes
> http://geotoolsnews.blogspot.co.at/2013/06/geotools-93-released.html
> There is almost no feed back from the community, enhancements are done
> based on my experience or from requirements sent to me by David Adler
> (working at IBM). Fortunately, I have a mandate from a customer to maintain
> this module. Anyways, I would be happy to get assistance from Brett.
>
> @Brett. We have two separate image modules, one serving image date from
> the file system and one using JDBC databases. Would be nice to merge this
> code into one module, but it is not an easy job. Perhaps you are interested.
>
> Cheers
> Christian
>
>
>
>
>
> 2013/6/26 Andrea Aime 
>
>> On Wed, Jun 26, 2013 at 8:15 AM, Brett Walker <
>> brett.wal...@geometryit.com> wrote:
>>
>>>  Andrea,
>>>
>>> ** **
>>>
>>> It was my misunderstanding on my part. It was trying to have a
>>> discussion which would educate subsequent commits. This being the first of
>>> several. I should have had the discussion on this mailing list rather on
>>> the pull request.
>>>
>>> ** **
>>>
>>> The pull request (PR#208) is finished. Could you provide feedback or
>>> commit it please.
>>>
>>
>> Will do the incoming weekend. Others might want to review the pull
>> request sooner and merge it,
>> some review is needed (unless you're the maintainer of a module or got
>> the ok from the maintainer
>> to commit directly), but it does not have to be my review, since we're
>> talking about something that's
>> shared among all modules, nobody is specifically maintaining it
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> --
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Pull Request Policy

[Chris Holmes]

On Tue, Jun 25, 2013 at 11:28 PM, Brett Walker
wrote:

>  Thanks Chris for your questions.
>
> ** **
>
> I’m interested to learn more about image sources as it would complement my
> experience in database sources (JDBCC) such as Oracle and PostgreSQL. Keen
> to get my teeth in the DB2 module also.
>
> **
>

Awesome. I think image sources are where we've traditionally been a bit
weaker, but the geosolutions crew has been turning that around for years
now, and the new grid coverage stuff landing soon is going to be a big step
forward. I suspect they can come up with some cool ways to help out there.

One idea I had (though I've not thought it through a lot so someone may
shoot it down) is to do a 'directory of image files', just like we have a
'directory of shapefiles' on the vector side. I think this has not been
possible because of our old architecture, but with the new work landing I
think it might be something nice to add. It's a pain now to select every
image file - would be much better to just point at a directory and have it
find everything. I think there are some importers that help with this, but
logically I believe it'd make more sense to have few 'coverage stores' -
have them be directories with coverages of all the images in them. I
believe the directory of image files might help get you up to speed, and
then open up a lot more interesting directions to make it far easier to
configure image sources. We've got all the power to do amazing stuff, but
it's not at the point where you can just point geoserver at a directory of
random sources and have it do the right thing, or even be super easily
configured for the right thing.

DB2 usually can use some love. We've had a few people come in and do great
work on it, but I don't think it's had a long term consistent maintainer.
So there's probably some updates and optimizations to be done there.



> **
>
> My more immediate areas of interest are around the build process.
> Upgrading dependencies, plugins. Full support for Maven3 and JDK7.
>
> **
>

Awesome, that's definitely thankless work that I'm sure will be appreciated.


> **
>
> Documentation needs attention also.
>
> **
>

As are docs, definitely would be great to get GeoTools better there, help
reveal more of its power to newer users.


> **
>
> PR#208 is one I have submitted that has been sitting around for a while.
> PR#217 and PR#18 submitted by others seems good. I have a concern that
> PR#217 might break backwards compatibility.
>
> **
>

Cool, I'll let the real devs comment on those :)

Chris


> **
>
> Brett
>
> ** **
>
> *From:* chol...@openplans.org [mailto:chol...@openplans.org] *On Behalf
> Of *Chris Holmes
> *Sent:* Wednesday, 26 June 2013 1:17 PM
> *To:* Brett Walker
> *Cc:* geotools-devel@lists.sourceforge.net
>
> *Subject:* Re: [Geotools-devel] Pull Request Policy
>
> ** **
>
> Welcome Brett! 
>
> ** **
>
> As you can tell we get too many requests from people who aren't actually
> interested in joining up and helping out. When I first read your message I
> actually suspected you might be up for contributing, but I can see how it
> was ambiguous. Would have been good to mention the pull request you made,
> since it looks like a couple core devs were excited about it. I'm glad
> you're up for the gift economy that is open source.
>
> ** **
>
> I think our unofficial rule is (or at least was, it's been way too long
> since I've committed to GeoTools) to have at least two or three solid,
> reasonably sized patches before commit access. I see your PR at
> https://github.com/geotools/geotools/pull/208, would be good to link to
> the patches you've done in the past.
>
>
> But now that everyone knows you're interested in becoming a committer and
> helping out I'd guess someone will be inclined to review your PR much
> sooner. So I'd say just poke people on your PR's, with offers to help out
> on issues they wish were done. And when you make new PR's just poke the
> list with what it's about.
>
> ** **
>
> Sounds like you have great experience for GeoTools though, so will be
> really great to have you aboard. I'm also curious about what areas of
> GeoTools you're interested in. Is it just the parts you have experience in?
> Or are there newer topics you're interested in diving in to? There are
> definitely some key areas of GeoTools where we only have one or two expert,
> so would be great if you're interested in some of those.
>
> ** **
>
> Chris
>
> ** **
>
> On Tue, Jun 25, 2013 at 11:02 PM, Brett

Re: [Geotools-devel] Pull Request Policy

[Chris Holmes]

Welcome Brett!

As you can tell we get too many requests from people who aren't actually
interested in joining up and helping out. When I first read your message I
actually suspected you might be up for contributing, but I can see how it
was ambiguous. Would have been good to mention the pull request you made,
since it looks like a couple core devs were excited about it. I'm glad
you're up for the gift economy that is open source.

I think our unofficial rule is (or at least was, it's been way too long
since I've committed to GeoTools) to have at least two or three solid,
reasonably sized patches before commit access. I see your PR at
https://github.com/geotools/geotools/pull/208, would be good to link to the
patches you've done in the past.

But now that everyone knows you're interested in becoming a committer and
helping out I'd guess someone will be inclined to review your PR much
sooner. So I'd say just poke people on your PR's, with offers to help out
on issues they wish were done. And when you make new PR's just poke the
list with what it's about.

Sounds like you have great experience for GeoTools though, so will be
really great to have you aboard. I'm also curious about what areas of
GeoTools you're interested in. Is it just the parts you have experience in?
Or are there newer topics you're interested in diving in to? There are
definitely some key areas of GeoTools where we only have one or two expert,
so would be great if you're interested in some of those.

Chris


On Tue, Jun 25, 2013 at 11:02 PM, Brett Walker
wrote:

> Hi Jody,
>
> I take this as an invitation to request commit access. May I have commit
> access please?
>
> A bit about myself.
>
> My name is Brett Walker from Hobart, Tasmania. I work for Geometry (
> http://www.geometryit.com/) that has an expertise in spatial
> applications, for nearly 10 years. I have be a using Java, much longer,
> almost twenty years. And I have experience with other languages such as
> assembly, C/C++ & .NET.
>
> Geometry developed a product called Exposure that is very similar to
> GeoServer. Our reliance on Exposure for spatial solution has diminished as
> Geometry has turned towards GeoServer and Geotools for providing solutions.
>  I have contributed small patches to GeoTools in the past.
>
> I have had exposure to a number of Web Service Technologies and various
> Database technologies, particular Oracle and PostgreSQL.
>
> I would be helping GeoTools outside of company time and not constrained by
> copyright/licence agreements with Geometry. I have no agenda driven by
> company needs or other concerns.
>
> This is an offer of assistance in the spirit of the Open Source community.
> I want to help. I would like to be come just a committer and, not at the
> moment, have additional responsibilities such as a module maintainer.
>
> GeoTools is a large body of work. I have lots to learn but am very willing.
>
> While this is brief, I am open to further queries.
>
> Please consider my request for commit access,
> Brett
>
> -Original Message-
> From: Jody Garnett [mailto:jody.garn...@gmail.com]
> Sent: Wednesday, 26 June 2013 8:09 AM
> To: Brett Walker
> Cc: Geotools-Devel list
> Subject: Re: [Geotools-devel] Pull Request Policy
>
> Same as a patch in Jira - should have a test case, subject to volunteer
> time, etc...
>
> Pull request coming in via our change control procedure are planned during
> our bi-weekly meeting, and in the case of GeoSolutions API change the
> subject of scheduling. In this case geotools is entering lockdown shortly,
> so as a volunteer I want to see any API changed done *now* so it does not
> wait 6 months.
>
> We have a small number of active participants, if your organization needs
> more timely service consider taking part in the project (as a module
> maintainer or obtaining commit access). Some groups that have restrictions
> on programming in public go the commercial support option.
>
> We're there any pull requests in particular you were concerned with?
>
> --
> Jody Garnett
>
> On 26/06/2013, at 7:39 AM, Brett Walker 
> wrote:
>
> > Hi,
> >
> > What is the policy/procedure/expectation for pull requests that have
> been submitted for more than a couple of weeks?
> >
> > There are a number of pull requests that have been sitting 'dormant' for
> a while. Do they sit forever open with no feedback, or should they be
> closed, with comment, if not found suitable.
> >
> > It seems that pull requests from developers with commit access have
> preference with daylight second.
> >
> > Ignoring worthwhile patches could appear to give the cold shoulder to
> the wider community.
> >
> > Your thoughts please,
> > Brett
> >
> > Sent from my iPad
> > --
> >  This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > ___
> > GeoTools-Devel mailing list

Re: [Geotools-devel] [Geoserver-devel] Setting up a Windows Build Server for GeoTools and GeoServer

[Chris Holmes]

+1 here, sounds like a great step forward. Thanks for contributing the
server and time resources.


On Thu, Jun 6, 2013 at 5:45 PM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Cool,
> I guess we have enough consensus for us to move on with this.
> I will let you know once we have something in place ( I would not hold
> my breath though as it is a pretty busy
> period, I would say 3 to 5 weeks to get the VM in place. Earlier than
> that if we get one or two rainy weekends ;) )
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer training in Milan, 6th & 7th June 2013! Visit
> http://geoserver.geo-solutions.it for more information.
> ==
>
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39 333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> On Thu, Jun 6, 2013 at 3:41 PM, Christian Mueller
>  wrote:
> > +1, thanks for the work
> >
> >
> > 2013/6/6 Justin Deoliveira 
> >>
> >> Sorry, definitely no objection here. +1 and thanks for the work on this.
> >>
> >>
> >> On Wed, Jun 5, 2013 at 11:12 PM, Simone Giannecchini
> >>  wrote:
> >>>
> >>> Any feedback from OpenGeo folks? :)
> >>>
> >>> I am hoping to get minimum consensus from most (all?) the devs before
> >>> doing anything. I believe otherwise the effort would be
> >>> pointless.
> >>>
> >>> (I don't intend to push anyone on this, I just don't want to loose
> >>> momentum :) )
> >>>
> >>> Regards,
> >>> Simone Giannecchini
> >>> ==
> >>> GeoServer training in Milan, 6th & 7th June 2013! Visit
> >>> http://geoserver.geo-solutions.it for more information.
> >>> ==
> >>>
> >>> Ing. Simone Giannecchini
> >>> @simogeo
> >>> Founder/Director
> >>>
> >>> GeoSolutions S.A.S.
> >>> Via Poggio alle Viti 1187
> >>> 55054  Massarosa (LU)
> >>> Italy
> >>> phone: +39 0584 962313
> >>> fax: +39 0584 1660272
> >>> mob:   +39 333 8128928
> >>>
> >>> http://www.geo-solutions.it
> >>> http://twitter.com/geosolutions_it
> >>>
> >>> ---
> >>>
> >>>
> >>> On Wed, Jun 5, 2013 at 3:29 PM, Rahkonen Jukka
> >>>  wrote:
> >>> > +1
> >>> >
> >>> >
> >>> >
> >>> > -Jukka-
> >>> >
> >>> >
> >>> >
> >>> > Andrea Aime wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Jun 4, 2013 at 10:27 AM, Ben Caradoc-Davies
> >>> >  wrote:
> >>> >
> >>> > +1 for the Windows build server to be considered as important as
> Linux,
> >>> > with notifications sent to the respective developer lists.
> >>> >
> >>> >
> >>> >
> >>> > +1 here too
> >>> >
> >>> >
> >>> >
> >>> > Cheers
> >>> >
> >>> > Andrea
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > ==
> >>> >
> >>> > GeoServer training in Milan, 6th & 7th June 2013!  Visit
> >>> > http://geoserver.geo-solutions.it for more information.
> >>> > ==
> >>> >
> >>> >
> >>> >
> >>> > Ing. Andrea Aime
> >>> >
> >>> > @geowolf
> >>> >
> >>> > Technical Lead
> >>> >
> >>> >
> >>> >
> >>> > GeoSolutions S.A.S.
> >>> >
> >>> > Via Poggio alle Viti 1187
> >>> >
> >>> > 55054  Massarosa (LU)
> >>> >
> >>> > Italy
> >>> >
> >>> > phone: +39 0584 962313
> >>> >
> >>> > fax: +39 0584 1660272
> >>> >
> >>> > mob: +39 339 8844549
> >>> >
> >>> >
> >>> >
> >>> > http://www.geo-solutions.it
> >>> >
> >>> > http://twitter.com/geosolutions_it
> >>> >
> >>> >
> >>> >
> >>> > ---
> >>> >
> >>> >
> >>> >
> >>> >
> --
> >>> > How ServiceNow helps IT people transform IT departments:
> >>> > 1. A cloud service to automate IT design, transition and operations
> >>> > 2. Dashboards that offer high-level views of enterprise services
> >>> > 3. A single system of record for all IT processes
> >>> > http://p.sf.net/sfu/servicenow-d2d-j
> >>> > ___
> >>> > Geoserver-devel mailing list
> >>> > geoserver-de...@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>> >
> >>
> >>
> >>
> >>
> >> --
> >> Justin Deoliveira
> >> OpenGeo - http://opengeo.org
> >> Enterprise support for open source geospatial.
> >>
> >>
> >>
> --
> >> How ServiceNow helps IT people transform IT departments:
> >> 1. A cloud service to automate IT design, transition and operations
> >> 2. Dashboards that offer high-level views of enterprise services
> >> 3. A single system of record for all IT processes
> >> http://p.sf.net/sfu/servicenow-d2d-j
> >> ___
> >> Geoserver-devel mailing list
> >> geoserver-de...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>
> >
> >
> >
> > --
> > DI Christian Mueller MSc (GIS

Re: [Geotools-devel] Proposal: upgrading the shapefile module to shapefile NG

[Chris Holmes]

+1 here, sounds awesome.


On Wed, Apr 10, 2013 at 10:49 AM, Justin Deoliveira wrote:

> Sorry for the late vote, +1.
>
>
> On Tue, Apr 9, 2013 at 1:57 AM, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> Ciao Andrea,
>> I tried to put my +1 on the page but it looks like I can't log in.
>> I'll try to reset the pwd, but, yeah, this is a +1.
>>
>> Regards,
>> Simone Giannecchini
>> ==
>> GeoServer training in Milan, 6th & 7th June 2013! Visit
>> http://geoserver.geo-solutions.it for more information.
>> ==
>>
>> Ing. Simone Giannecchini
>> @simogeo
>> Founder/Director
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob:   +39 333 8128928
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> On Sun, Apr 7, 2013 at 4:22 PM, Andrea Aime
>>  wrote:
>> > Hi all,
>> > here is a proposal to upgrade the shapefile-ng module to supported
>> status,
>> > and make shapefile become (temporarily) an unsupported module named
>> > shapefile-old:
>> >
>> http://docs.codehaus.org/display/GEOTOOLS/Migrate+shapefile+to+shapefile-ng
>> > and here is the pull request:
>> > https://github.com/geotools/geotools/pull/176
>> >
>> > The API changes are minimal, most well written client code won't
>> notice, the
>> > code builds fine, GeoServer only needed a couple one liners to build and
>> > work against the new shapefile:
>> > https://github.com/geoserver/geoserver/pull/204
>> >
>> > I have no word from uDig, as far as I know they are stuck on an old
>> version
>> > of GeoTools since they still haven't upgraded to the changes of the
>> feature
>> > collection cleanup.
>> >
>> > I believe this is a good time to perform the swap as we have months
>> ahead
>> > before the release, if there are lingering issues we should be able to
>> spot
>> > them and sort them out before the release
>> >
>> > Please vote/discuss
>> >
>> > Cheers
>> > Andrea
>> >
>> >
>> > --
>> > ==
>> > Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more
>> > information.
>> > ==
>> >
>> > Ing. Andrea Aime
>> > @geowolf
>> > Technical Lead
>> >
>> > GeoSolutions S.A.S.
>> > Via Poggio alle Viti 1187
>> > 55054  Massarosa (LU)
>> > Italy
>> > phone: +39 0584 962313
>> > fax: +39 0584 1660272
>> > mob: +39 339 8844549
>> >
>> > http://www.geo-solutions.it
>> > http://twitter.com/geosolutions_it
>> >
>> > ---
>> >
>> >
>> --
>> > Minimize network downtime and maximize team effectiveness.
>> > Reduce network management and security costs.Learn how to hire
>> > the most talented Cisco Certified professionals. Visit the
>> > Employer Resources Portal
>> > http://www.cisco.com/web/learning/employer_resources/index.html
>> > ___
>> > GeoTools-Devel mailing list
>> > GeoTools-Devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
>> >
>>
>>
>> --
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
GeoTools-Deve

Re: [Geotools-devel] Contribution Agreement Clarity

[Chris Holmes]

I'm very concerned by this too. It sucks to not get contributions from
Google. But it's even worse as an indicator of things that may scare off
others who are similar.

I'd be very much in favor of just using the Apache one, and moving to it
quickly. To reiterate for all, this is just for the contribution agreement.
We could adapt the Apache one to so it assigns copyright to LGPL pretty
easily I imagine. So we're not talking about changing the license, just the
way the license gets assigned to GeoTools.

C


On Wed, Jan 30, 2013 at 1:42 AM, Andrea Aime
wrote:

> On Wed, Jan 30, 2013 at 1:30 AM, Frank Warmerdam wrote:
>
>> Folks,
>>
>> I have finally got a clear response back from our internal legal
>> reviewer to my request to offer refinement to the text of the GeoTools
>> contributor agreement.  He indicated that the agreement has multiple
>> issues, and that it couldn't be easily corrected to meet our
>> (Google's) expectations.  He suggested we might want to start over
>> with a stock agreement such as Apache's.
>>
>
> You mean, this one?
> http://www.apache.org/licenses/icla.txt
>
>
>>
>> I'm not interested in pushing a complete rework of the contribution
>> agreement, so at this point I am letting the matter drop and it
>> appears that Google will not be a significant contributor to GeoTools.
>>  I'm rather bummed.
>>
>
> So am I. If the licence was the issue, I could understand, but being
> blocked by the contributor agreement itself I find rather worrysome.
> I believe we should at least consider using the Apache one.
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Killing the net.opengis.wfsv module

[Chris Holmes]

+1 - kill it.


On Tue, Dec 18, 2012 at 2:53 AM, Jody Garnett wrote:

>  Good call Andrea, sorry I missed that one during my cleanup.
>
> --
> Jody Garnett
>
> On Monday, 17 December 2012 at 8:17 PM, Andrea Aime wrote:
>
> Hi,
> I'm writing this mail to propose we get rid of the net.opengis.wfsv module.
> The module was used in conjunction with versioned postgis and the
> GeoServer WFSV
> module to support versioning on top of WFS.
>
> The thing never got traction and eventually both the postgis versioning in
> GeoTools
> and the wfsv module in GeoServer got removed, net.opengis.wfsv remained
> there mostly because we forgot about it, but without the others it's
> useless.
>
> So, how about we save a bit of space and a bit of build time and remove
> the module
> from the source altogheter?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Chris Holmes]

On Wed, Oct 24, 2012 at 2:45 AM, Andrea Aime
wrote:

> On Tue, Oct 23, 2012 at 7:49 PM, Chris Holmes  wrote:
>
> >> However, it does not make sense to duplicate what we already have for
> >> free, either.
> >> If it's not too much trouble, why not remove those as well?
> >>
> >
> > +1 - seems like removing them could help more with like our weird memory
> > bloat more than the actual download size no?
>
> Indeed.
> Also, to lower our memory bloat the next big win is to switch to GWC 1.4.x
> and
> have the disk quota mechanism work off H2 instead of Berkely DB (a 2MB
> win, also noticeable in the downloads)
>
>
Any reason not to do that soon? I'd love to see those improvements on
GeoServer master, I've psyched to read about the advances on the GWC list,
sounds like great work Andrea. And it seems like it'd be good to get in
sooner rather than later so we can start ironing out any bugs.


> Cheers
> Andrea
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Chris Holmes]

On Tue, Oct 23, 2012 at 9:08 AM, Andrea Aime
wrote:

> On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira 
> wrote:
>
> > Indeed. And also while we are at it i will pose the question. There is
> also
> > the opportunity to prune out some other xml dependencies as well. Namely
> > jdom, xpp and stax from what i can tell. All seem to have equivalents
> built
> > into the jdk. Is it worth pruning them out?
>
> Well, it is not a win as big as with Xerces:
>
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> ls -lh stax-*
> -rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
> -rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> ls -lh jdom*
> -rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls
> -lh xpp*
> -rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
> -rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar
>
> However, it does not make sense to duplicate what we already have for
> free, either.
> If it's not too much trouble, why not remove those as well?
>
>
+1 - seems like removing them could help more with like our weird memory
bloat more than the actual download size no?


> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] GeoServer and GeoTools releases temporary out of synch

[Chris Holmes]

Yeah, no concern here, I'm +1 to just go for it with 8.1. My 8.0.1 was just
an alternate suggestion, I'm definitely good with 8.1.

On Thu, Aug 16, 2012 at 6:03 AM, Andrea Aime
wrote:

> On Thu, Aug 16, 2012 at 2:47 PM, Justin Deoliveira 
> wrote:
>
>> And the idea is that two minor releases in one month is too much?
>
>
> Seemed like a bit too much, but if no one else is concerned about it I'm a
> go for it too :)
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:   +39 0584 962313
> mob:   +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoServer and GeoTools releases temporary out of synch

[Chris Holmes]

8.0.1 seems reasonable to me? Doesn't feel extreme after 15 days, and
represents some minor improvements/fixes. And doesn't make us do some weird
geoserver specific tag.

On Wed, Aug 15, 2012 at 10:06 AM, Andrea Aime
wrote:

> Hi,
> with the "time boxed" release model proposal it was stressed how important
> it is
> to have synched up releases (since GeoServer needs to make a GeoTools
> release anyways
> when doing its own and that has the benefit of making Geotools frequent
> releases).
>
> However, now we have GS 2.2-RC2 and GT 8.0 out.
> What happens for GS 2.2-RC3? Are we going to release GT 8.1 after just 15
> days
> of the last release? That seems a bit extreme to me.
> And what if we have to make another RC for some reason, 8.2 after another
> two weeks?
> Bleck...
>
> Right now there are handful of issues resolved after 8.0:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOT+AND+fixVersion+%3D+18691+AND+status+%3D+Resolved
>
> I guess we can try to just tag and deploy, but not release on SF, calling
> the tag
> something like 8.0-GS-2.2-RC3
>
> Maybe next time we should try to pay attention and synch up the finals of
> each
> better
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:   +39 0584 962313
> mob:   +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [ExternalEmail] Migrate ComplexFeature Parsing work off wfs-ng

[Chris Holmes]

Seems sensible in general that Complex Feature parsing and building would
be independent on wfs datastore. People might want to use it standalone,
just reading in some gml files. Then wfs-ng should just call that module,
no?

On Fri, Jul 27, 2012 at 2:46 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> Adam,
>
> are you asking for a new unsupported module?
> http://docs.geotools.org/latest/developer/procedures/create.html
>
> How much of Gabriel's wfs-ng do you need, or are you proposing to fork it?
>
> Gabriel, what are your plans for your fork of wfs-ng? Do you intend to
> merge it back into github geotools/geotools or is it stalled?
>
> It would be good to avoid code duplication if possible.
>
> Kind regards,
> Ben.
>
> On 27/07/12 14:26, adam.br...@csiro.au wrote:
> > Hi all,
> >
> > I am doing some work to add ComplexFeature parsing and building support
> >  to GeoTools. At the moment
> > it’s on my own fork of wfs-ng
> > . The decision
> > around me doing this work on this branch was arrived at in this
> > conversation on the mailing list
> > <
> http://sourceforge.net/mailarchive/forum.php?thread_name=CAJoZhK1-HvOntv1%3D9o1eYMrXuFThW5Vv%2Bnw5YaZE__bER_fecg%40mail.gmail.com&forum_name=geotools-devel
> >.
> >
> > I want to know if I can migrate my changes off wfs-ng and onto the
> > GeoTools trunk (or other?) because I’m currently blocked by compilation
> > problems in wfs-ng which are outside of my area of knowledge.
> >
> > Many thanks,
> >
> > Adam Brown
> > Software Programmer *|* CSIRO Earth Science and Resource Engineering
> >
> > Phone: +61 8 6436 8956* |*
> > adam.br...@csiro.au  *|* www.csiro.au
> > 
> > Address: Australian Resources Research Centre, 26 Dick Perry Avenue,
> > Kensington WA 6151
> >
>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Moving code from GeoServer to GeoTools

[Chris Holmes]

Yup. Sorry for missing that email, sounds great.

On Wed, May 16, 2012 at 2:02 AM, Andrea Aime
wrote:

> On Tue, May 15, 2012 at 11:51 PM, Chris Holmes 
> wrote:
> > For this case in particular, if we want to move faster, I feel
> comfortable
> > approving the porting of all code done by OpenGeo employees on OpenGeo
> time
> > to GeoTools. It looks like Simone also did some of the work, so I'd say
> if
> > he is also comfortable with porting it over then we have approval. Or we
> can
> > ask the PSC.
>
> Which I already did a few days ago collecting, so far, 6 positive votes:
>
> http://osgeo-org.1560.n6.nabble.com/PSC-Motion-allow-porting-portions-of-GetLegendGraphics-back-to-GeoTools-td4974361.html
>
> I guess we can consider it approved?
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Rebooting the "IRC" meetings?

[Chris Holmes]

Ah, I didn't see that Jody's had an actual day, was thinking it was
just the time.

Let's do the monday, so we're not getting in to the weekend for Australians.

I have to check my conference schedule, may be helping give a workshop
right then, but let's just get things rolling.

On Tue, May 8, 2012 at 10:48 AM, Jody Garnett  wrote:
> Friday works fine for me too.
>
> Earlier in the thread Jody proposed May 14 though:
>
> A different day of the week will be fine; I would prefer thursday in order
> to have my Friday night free.
>
> At least it sounds like the timeslot will work.
>
> Jody
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Rebooting the "IRC" meetings?

[Chris Holmes]

Ok, let's keep moving on this.

I think we should stick with the 'voice' idea and see if we can get it
to work. We can complement with an etherpad to take real time notes on
all that is said, so we have a transcript. And a chat window (irc or
an integrated webex one) to drop links and so people who can't do
voice can follow along.

Are we up for trying one this week? Thursday or Friday? I'm out next
week at a conference, though I don't necessarily need to be there -
don't think we should get too hung up on trying to coordinate
absolutely everyone, just pick a reasonably good time.

And then do them regularly. Do we want to do once every two weeks?
More or less often?

Looking at the list discussion I imagine the first topic should be
Releases - scheduling and automation. Anybody else have other topics
to discuss?

On Wed, May 2, 2012 at 6:03 AM, Andrea Aime
 wrote:
> On Wed, May 2, 2012 at 9:35 AM, Ian Turton  wrote:
>>
>> On 1 May 2012 23:01, Simone Giannecchini
>>  wrote:
>> > Ciao Justin,
>> > I would rather go for voice, as my experience with IRC was not very
>> > good.
>> >
>>
>> That would be a problem for me as I can do IRC while in the office but
>> voice meetings would be annoying for my office mates :-) Plus I
>> suspect that our fire wall would have more of a problem with webex. I
>> also prefer irc since it is easier for people who can't make the
>> meeting to read the notes rather than rely on someone to take minutes
>> and post them later.
>
>
> Hmm... chat typing is slow enough that it will take 2 hours to do a gt/gs
> meeting side by side, which is too much time.
> If we cannot keep them short I fear we'll go back to no meetings
> in a very short time.
>
> Wondering if we can do something hybrid, mainly voice with people
> that cannot "talk" just listen and comment on a textual chat?
>
> Webex wise, no problem for me, but mind, voice support does not work
> on Linux (or at least, never managed to make it work on Ubuntu) because
> the java applet pretends to be the only one accessing the sound subsystem,
> not being able to (since the sound mixer is always on) it fails.
> I normally temporarily start up a Windows VM to do Webex
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Discussing a switch to a time boxed release model

[Chris Holmes]

+1 on all this.

Perhaps two GSIP's should come out of this? One for the release model
/ schedule. And then another for automation improvements? Or perhaps
we don't need a GSIP for that, but should get a jira and a plan of
attack for it.

On Thu, May 3, 2012 at 5:08 AM, Alessio Fabiani
 wrote:
> Hi all,
> I really would like to move forward with this proposal.
>
> I'm currently having a lot of difficulties to get an idea of a plan on wich
> version of GeoServer/GeoTools schedule on my projects, so having a
> programmatic release project would be very welcomed and useful.
>
> High automation also is a great idea, would very very helpful for the
> release process which usually takes a lot of time and resources.
>
> I also volunteer to provide help as much as possible to have all of this
> implemented soon.
>
> Regards,
>         Alessio.
>
> ---
> Ing. Alessio Fabiani
> Founder / CTO GeoSolutions S.A.S.
>
> GeoSolutions S.A.S.
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: (+39) 0584 96.23.13
> fax:     (+39) 0584 96.23.13
> mobile:(+39) 331 62.33.686
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com
> http://www.linkedin.com/in/alessiofabiani
> https://twitter.com/alfa7961
> http://twitter.com/geosolutions_it
> ---
>
>
>
> On Wed, May 2, 2012 at 6:27 PM, Andrea Aime 
> wrote:
>>
>> On Tue, May 1, 2012 at 5:54 PM, Justin Deoliveira 
>> wrote:
>>>
>>> In general I think it looks great, a few things though. I think given the
>>> current effort to put out releases 1 month is probably asking a bit much
>>> given the resources we have on the project. So I think to do one month
>>> cycles we really do need to better automate our release process with a
>>> hudson job that does most of the work.
>>>
>>> It would also be good to have some better defined (and perhaps stricter)
>>> guidelines about what is acceptable to commit given the current phase of an
>>> iteration. For instance obviously once we move to a stable or hardening
>>> phase GSIP's that drastically alter the core are out of the question. It
>>> would be good if we had a more concrete definition of "drastically alter the
>>> core". Like should we be strict and say stable/hardening means strictly only
>>> bug fixes? With a faster release cycle it could make more sense to have
>>> stricter guidelines since if you don't get something into this release there
>>> is one not too far off. This is exactly why we ran into the fluerry of gsip
>>> issue... with another release 1.5 years away it certainly puts the pressure
>>> on to cram stuff in.
>>>
>>> Anyways, great stuff. I like where this is going, big things from my
>>> standpoint.
>>>
>>> 1. better automation of release, which i am happy to help with
>>> 2. better guidelines for what type of development is acceptable during
>>> what phases
>>
>>
>> Fully agree on the higher automation (tried to discuss some ideas about it
>> in my
>> original mail).
>>
>> About what is acceptable and not, what about the following:
>> - stable series: only bug fixes and new features that do not require API
>> changes
>>   or large patches to existing systems (that is, if you are contributing a
>> new module
>>   the patch can be as large as you want, but a "bug fix" that rewrites
>> half of WFS
>>   is not welcomed unless the PSC really really wants such change badly in)
>> - trunk: free reign, but large changes still need a GSIP and reviews
>> - hardening: no new features, only bug fixing to make sure people
>> concentrate on
>>   that, if you have something new it has to go on trunk for the time being
>>
>> The above should be, imho, taken more or less as strict rules that the PSC
>> should
>> try to enforce (the above, or whatever we come up with).
>> That said, the PSC should be allowed to decide outside of the above rules
>> in case of dire necessity (e.g., something that could threaten or damage
>> the
>> project severely if not done outside of the rules).
>>
>> Cheers
>> Andrea
>>
>> --
>> ---
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax:      +39 0584 962313
>> mob:    +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.youtube.com/user/GeoSolutionsIT
>> http://www.linkedin.com/in/andreaaime
>> http://twitter.com/geowolf
>>
>> ---
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/ja

Re: [Geotools-devel] [Geoserver-devel] Rebooting the "IRC" meetings?

[Chris Holmes]

I do like text records. I think one thing that could work well would
be to etherpad it, so a few people can take relevant notes at once.
Then we can post that etherpad transcript to the blog when we're done.
I'd be happy to try to take lead on writing, as long as there'd be a
couple backups for when I'm talking or when I miss stuff.

On Wed, May 2, 2012 at 12:01 AM, Simone Giannecchini
 wrote:
> Ciao Justin,
> I would rather go for voice, as my experience with IRC was not very good.
>
> We are happy to host the meetings with our webex account so that we
> can register them and try to make them available afterwards, putting
> them somewhere on one of our demo servers.
> Baseline rationale behind resurrecting the meetings was to have an
> agile way to try and coordinate lightly not to add overhead again, so
> the less formalities, the better IMHO.
>
> Regards,
> Simone Giannecchini
> ---
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Founder
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 333 8128928
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/simonegiannecchini
> http://twitter.com/simogeo
>
> ---
>
>
> On Tue, May 1, 2012 at 4:12 PM, Justin Deoliveira  
> wrote:
>> A big +1 here. A few thoughts.
>>
>> I agree voice is more productive but has a few potential drawbacks. Harder
>> to get a transcript for one. Also some non-native english speakers may
>> prefer the IRC medium rather than voice, but I will let others comment on
>> that.
>>
>> I think the two week recurrence is a good idea and +1 on having one
>> geotools/geosever/udig/java ... irc meeting. I guess the idea would be to
>> use the geotools list for any organization required, like coming with agenda
>> items before hand, etc...
>>
>> Anyways, glad to see this coming back. When do we kick off the first one?
>>
>> On Tue, May 1, 2012 at 1:20 PM, Andrea Aime 
>> wrote:
>>>
>>> Hi,
>>> talking with Chris last week we were discussing the general lack of
>>> coordination
>>> that has been affecting both GeoTools and GeoServer in the last year or
>>> so.
>>>
>>> It would be nice to try and open a bit communications channels with a
>>> means
>>> that gives more opportunity for people to talk about what they are doing,
>>> priorities
>>> expectations and needs.
>>>
>>> At the same time I believe we need to avoid getting bogged down into
>>> something
>>> that would make people disregard the meetings because they are using too
>>> much
>>> time.
>>>
>>> I've sent the mail to both geotools and geoserver ml because I'm thiking
>>> of doing
>>> a shared one between the two projects.
>>> This is a quick braindump of how it may look like (mostly to promote
>>> discussion
>>> on the topic):
>>>
>>> - voice meeting, to keep things short and get maximum bandwidth (skype,
>>> gtalk?
>>>   with a chat fallback for needs such a sharing links, pasting text,
>>> raising hand
>>>   to talk next in case the discussion gets "busy" with lots of people
>>> willing to say
>>>   something
>>> - ideally time boxed to half an hour with the ability to expand on a as
>>> need basis
>>> - a meeting every two weeks
>>> - topics to be discussed scheduled in advance (with a default "what's up
>>> one"),
>>>   with people signing up on the
>>>   topics that they are interested to discuss (so that we can cover first
>>> the ones
>>>   that most people are interested in, and keep for later the ones with a
>>> smaller
>>>   audience, allowing people to leave earlier if they need to)
>>> - terse textual log only showing the topics discussed and the decision
>>> taken, to be
>>>   edited collaboratively on something like etherpad (which is gone, but
>>> there
>>>   is plenty of replacements around, including, if we want too, Google
>>> Docs)
>>> - a meeting that discusses both GeoTools and GeoServer, in that order.
>>>   Actually, it can be something like "GeoTools tribes" meeting, with a
>>> first
>>>   part where everybody is on board, and a second one where people
>>>   split up and discuss separately, if they want to, uDig, GeoServer and
>>> whatever
>>>   else they want
>>> - participation from PSC members somehow expected, other people can join
>>> at will
>>>
>>> If people from all time zones are interested we'll have to actually setup
>>> two meetings
>>> and do some follow up by mail, leveraging the logs:
>>>
>>> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20120601&p1=215&p2=179&p3=256&p4=196&p5=240
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ---
>>> Ing. Andrea Aime
>>> GeoSolutions S.A.S.
>>> Tech lead
>>>
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>>
>>> phone: +39 0584 962313
>>> fax:      +39 0584 962313
>

Re: [Geotools-devel] New plugin supporting upcoming POSTGIS 2.0 Raster

[Chris Holmes]

Oh, and awesome work Christian - it's quite cool to have pgraster available
in GeoServer.

On Sun, Sep 25, 2011 at 12:52 PM, Chris Holmes  wrote:

>
>
> On Sun, Sep 25, 2011 at 9:15 AM, Andrea Aime  > wrote:
>
>> On Sun, Sep 25, 2011 at 10:19 AM,  wrote:
>>
>>> I added a PostGis raster plugin to the imagemosaic-jdbc module on
>>> geotools trunk and did a backport to geotools 2.7.x
>>>
>>> The documentation is here
>>>
>>> http://docs.geotools.org/latest/userguide/library/coverage/pgraster.html
>>>
>>> Should I make an announcement on the user mailing lists ?
>>>
>>
>> That would work, a blog post would do fine as well.
>>
>> Looking at that page and wondering, is there any way to make the
>> configuration of those raster sources easier?
>> Ideally a graphical way to specify the data source (maybe even as
>> just ponting to an existing postgis store) and the table containing the
>> mosaic, provided that some conventions has been followed to setup
>> the data, would be really nice.
>> In case you're interested the GUI has pluggable API to provide your own
>> custom configuration panel, see the StoreEditPanel class, the
>> ArcSDECoverageStoreEditPanel is an example of how to do that
>> for coverages.
>>
>> I can't speak for others, but I personally find having to setup all these
>> configuration files really cumbersome
>>
>>
> Yeah, I agree with Andrea.  I think one thing that could work well is to
> have several datastore factories in the 'Image Mosaicing Pyramidal JDBC
> Plugin'.  Like one for PostGIS Raster, one for Oracle GeoRaster, one for
> the generic case, etc.  Many of the params should be known if a user is to
> select PostGIS.  I think Oracle has an example of more than one datastore
> factory.  Ideally then users are just specifying the connection params in
> the GUI.
>
> And I agree it'd be even better if one could just use one datastore
> connection for both vector and raster.  I think ArcSDE may have gotten that
> improvement, though not oracle and postgis.
>
>
>> Cheers
>> Andrea
>>
>>
>> --
>> ---
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax:  +39 0584 962313
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.youtube.com/user/GeoSolutionsIT
>> http://www.linkedin.com/in/andreaaime
>> http://twitter.com/geowolf
>>
>> ---
>>
>>
>> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New plugin supporting upcoming POSTGIS 2.0 Raster

[Chris Holmes]

On Sun, Sep 25, 2011 at 9:15 AM, Andrea Aime
wrote:

> On Sun, Sep 25, 2011 at 10:19 AM,  wrote:
>
>> I added a PostGis raster plugin to the imagemosaic-jdbc module on
>> geotools trunk and did a backport to geotools 2.7.x
>>
>> The documentation is here
>>
>> http://docs.geotools.org/latest/userguide/library/coverage/pgraster.html
>>
>> Should I make an announcement on the user mailing lists ?
>>
>
> That would work, a blog post would do fine as well.
>
> Looking at that page and wondering, is there any way to make the
> configuration of those raster sources easier?
> Ideally a graphical way to specify the data source (maybe even as
> just ponting to an existing postgis store) and the table containing the
> mosaic, provided that some conventions has been followed to setup
> the data, would be really nice.
> In case you're interested the GUI has pluggable API to provide your own
> custom configuration panel, see the StoreEditPanel class, the
> ArcSDECoverageStoreEditPanel is an example of how to do that
> for coverages.
>
> I can't speak for others, but I personally find having to setup all these
> configuration files really cumbersome
>
>
Yeah, I agree with Andrea.  I think one thing that could work well is to
have several datastore factories in the 'Image Mosaicing Pyramidal JDBC
Plugin'.  Like one for PostGIS Raster, one for Oracle GeoRaster, one for the
generic case, etc.  Many of the params should be known if a user is to
select PostGIS.  I think Oracle has an example of more than one datastore
factory.  Ideally then users are just specifying the connection params in
the GUI.

And I agree it'd be even better if one could just use one datastore
connection for both vector and raster.  I think ArcSDE may have gotten that
improvement, though not oracle and postgis.


> Cheers
> Andrea
>
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] FeatureVersioning interface api

[Chris Holmes]

Thanks for mentioning our work Andrea, we're definitely in the midst
of it right now.  And I totally agree that 3 implementations of the
interface would be ideal.

Walter, I'd love to get some collaboration going on this.  This email
a month ago would have been totally awesome, as we're getting closer
to the end of our currently funded versioning projects and so may not
be able to put lots of resources in to this.

But I'd love to hear more about your use cases and targets.  In one of
the proposals you say 'This is based largely on a simplified form of
the defunct versioned PostGIS project'.  Which versioned PostGIS
project?  What is the backend tech to do the versioning?  PostGIS?
With triggers / psgsql?  Or tables created by java?

And can you share about what it's needed for?  Why versioning is
needed?  Will it be in GeoServer?  Or uDig?  Or a custom project based
on GeoTools?

Am happy to give more details on our geogit work.  I have a draft
document explaining it, but haven't been able to push it out.  Our two
targets are the new OGC GeoSynchronization Service specification,
working on it for OWS-8 testbed, and part of our WFS2 work for IGN
France.  The geogit backend does more than either of those require, as
we're hoping to be able to use it as a base for full distributed
versioning, but want to implement the less complicated interfaces.
Both are pretty close to done, and should hopefully both get in to a
GeoServer 2.2, though we'll need some GSIP's.

Gabriel and Justin I'm sure will sound in with more on what we're
thinking at a GeoTools level for interfaces, as I think they've been
doing some work on that for GeoGit stores in WFS 2.

Chris

On Thu, Aug 4, 2011 at 4:07 PM, Andrea Aime
 wrote:
> On Thu, Aug 4, 2011 at 7:25 AM, Walter Deane  wrote:
>> I have submitted a proposal to include a FeatureVersioning and related
>> interfaces to GeoTools.
>>
>> These are new api classes but are based heavily on previous work in the
>> versioned postgis project.
>>
>> The current docs that this relates too are here:
>>
>> http://docs.geotools.org/latest/userguide/library/data/featuresource.html
>>
>> The proposal is here:
>>
>> http://docs.codehaus.org/display/GEOTOOLS/FeatureVersioning+interface+api
>
> I honestly liked better the old names, VersioningFeatureSource and
> VersioningFeatureStore.
>
> If you look into the existing naming conventions we have
> ReprojectingFeatureCollection,
> not FeatureReprojecting, ForceCoordinateFeatureReader, not
> FeatureForce and so on.
> The proposed naming would be uncharacteristic and suprising to the geotools
> user. -1 on it.
>
>> and the JIRA is here:
>>
>> http://jira.codehaus.org/browse/GEOT-3770
>>
>> There is a UML of the FeatureVersioning and FeatureSourceVersioning here:
>>
>> http://i.imgur.com/uoks4.png
>>
>> Any feedback would be appreciated.
>
> I know that OpenGeo is working on a distributed geographic version control
> system inspired by Git, GeoGit:
> https://github.com/opengeo/GeoGIT
>
> One thing that has always been missing from the old versioning API is the
> second and third implementation (they say you need at least three different
> implementations to nail down an interface).
> Would be interesting to get a perspective from Gabriel on the proposed
> interfaces and see if there is maybe small changes that could make
> a GeoGit based versioning system more "eager" to implement the
> versioning interfaces
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourc

Re: [Geotools-devel] Aggregating (wfs) datastore back from the ashes

[Chris Holmes]

Sounds awesome Andrea.

On Mon, Jul 25, 2011 at 6:58 AM, Andrea Aime
wrote:

> Hi,
> a long long time ago, in a svn revision far away, Lisasoft contributed
> an aggregating WFS data store:
>
> http://svn.osgeo.org/geotools/branches/2.4.x/modules/unsupported/aggregating-wfs/src/main/java/org/geotools/data/aggregating/
>
> Today I need something quite similar, yet, different enough that I'll
> have to reimplement
> it from scratch.
> I need an aggregating data store that:
> - can aggregate from any store, not just WFS (the use case is actually
> local database + various remote wfs)
> - still works on simple features only
> - has a target schema (the first one in list) and can aggregate the
> others with some
>  leeway on schema differences (ignore extra attributes, nullify
> missing ones, eventually
>  accept case differences in attribute names)
> - can tolerate some of the stores being unavailable
> - can get features in parallel from the sources and merge them in a
> single response (this one has still
>  the jury out, it might be done in a purely sequential way too)
> - is purely read only
> - assumes there are no feature duplicates around
> - the configuration would be programmatic, plus an eventual xml config
> file (likely xstream based for read/writes)
>
> The code would be based on content data store this time.
> Of course the code would be developed in unsupported and then
> eventually migrated to supported
> status.
>
> Opinions?
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
>
> --
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Release scheduling

[Chris Holmes]

Go for it.  Thanks a ton for taking this on.

On Tue, Nov 30, 2010 at 11:55 AM, Alessio Fabiani <
alessio.fabi...@geo-solutions.it> wrote:

> Hi all,
>
> I'm going to put out GeoTools 2.7-M4 and GeoServer 2.1-beta2 during the
> next two days.
>
> Any objection or suggestion?
>
> Alessio.
>
> ---
> Ing. Alessio Fabiani
> Founder / CTO GeoSolutions S.A.S.
>
> GeoSolutions S.A.S.
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: (+39) 0584 96.23.13
> fax: (+39) 0584 96.23.13
> mobile:(+39) 349 82.27.000
>
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com
> http://www.linkedin.com/in/alessiofabiani
> http://twitter.com/simogeo
> ---
>
>
>
> On Tue, Nov 30, 2010 at 5:23 PM, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> Dear All,
>> I have just asked alessio to move on, together with andrea on GS beta2 +
>> GT M4.
>>
>> This is our first release, even if it is not a major one, so I am hoping
>> we won't make too much noise.
>> Anyway, in case we get stuck somewhere we will ask for help on the ml.
>>
>> Ciao,
>> Simone.
>> ---
>> ===
>> Notice that our office phone number has recently changed!
>> Please, update your records!
>> ===
>> Ing. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Founder
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584962313
>> fax:  +39 0584962313
>> mob:+39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.linkedin.com/in/simonegiannecchini
>> http://twitter.com/simogeo
>>
>> ---
>>
>>
>> On Tue, Nov 23, 2010 at 9:36 PM, Jody Garnett wrote:
>>
>>> Hi Chris:
>>>
>>> Last I heard I was waiting for some work from GeoSolutions before
>>> releasing a GeoTools 2.7.0 - a new copy of ImageIO-Ext as used in the
>>> wms shootout.
>>>
>>> I expect to hear back shortly, I was not going to press the matter
>>> until the second week of December when I have a chance to do some open
>>> source work.
>>>
>>> So if we go before that; I would be happy to kick out a geotools
>>> milestone or release candidate; if not we are stuck waiting.
>>>
>>> Jody
>>>
>>> On Tue, Nov 23, 2010 at 11:31 PM, Chris Holmes 
>>> wrote:
>>> > So 2.1.x has a ton of features already, and I also know production
>>> instances
>>> > that are already running it and are stable.
>>> >
>>> > I think it's time we start the march to 2.1.0.  Talk about what else we
>>> want
>>> > to get in, when to do betas and the first RC, which we should make a
>>> true RC
>>> > - bug fixes only, if there's nothing major go 2.1.0.
>>> >
>>> > We have some capacity to do releases, and want to see 2.1.0 sooner
>>> rather
>>> > than later.  The only remaining thing we have underway that we want to
>>> get
>>> > in is WMS 1.3, which we are aiming to completely wrap up mid-december.
>>> What
>>> > else do people have in the queue?  GeoSolutions?  CSIRO?
>>> >
>>> >
>>> > I propose we all try to get a beta release out this week, a final beta
>>> out
>>> > mid-december, and a release candidate out the first week of January
>>> (the
>>> > 6th?).  From the final beta on we should be adding no new features.
>>> OpenGeo
>>> > can do one of the betas and at least the first RC.  We'd prefer the
>>> beta in
>>> > mid-december, so we can do it right after we finish WMS 1.3.  We can
>>> tweak
>>> > the dates, but I think it makes sense to set a hard deadline for when
>>> the
>>> > last features get in.  Thoughts?
>>> >
>>> >
>>> --
>>> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>>> > Tap into the largest installed PC base & get more eyes on your game by
>>> > optimizing for Intel(R) Graphics Technology. Get started today with the
>>> > Intel(R) S

Re: [Geotools-devel] WFS module back to supported

[Chris Holmes]

Wow, it'd be awesome to have a group of people taking this on.

After things get going there's one improvement you should definitely 
consider, and there's a chance we may get some funding to have Gabriel 
put some time in to this.  Namely caching WFS.  IMHO the WFS protocol 
isn't done quite right, as a naive client will make a new request on 
every pan and zoom.  Which is silly, because most WFS's have no notion 
of generalization, so it's just returning the same exact features back 
every time.  So a smart client could know that it has the full features, 
and not request them every time.

There's an OGC group working on 'geosynchronization', to have an RSS 
feed that notifies about changes to a WFS, so another WFS or a desktop 
client can synchronize against it.  There's a public discussion list 
https://lists.opengeospatial.org/mailman/listinfo/geosync-public (I'm 
not sure if the spec itself is public yet though, but if anyone is 
interested I can probably get you access from OGC).

So in an ideal architecture a WFS datastore could be configured against 
a WFS and its GeoSync feed, so that it can get the features once, store 
them in a local datastore, and then just check for changes.  But even if 
the WFS doesn't have a geosync feed we could provide some syncing option 
to users, like periodic cron check outs, or the ability to manually 
update.

Andrea's GSS module I think may have some good code to leverage for 
this, since the whole point of it is synchronization.

C


On 11/2/10 5:52 AM, Stefan A. Tzeggai wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> +1
>
> I have just started using the module in AtlasStlyer a week ago, and it
> can be used for some stuff. Still sometimes there are ugly bugs that i
> do not understand enought to fix alone.
>
> I would be in "the group".
>
> Steve
>
> Am 02.11.2010 10:43, schrieb Frank Gasdorf:
>> 1++
>> I'd like to get the module back to supported land too. But before we can
>> start I'd like to have some information about:
>>   Should we start from scratch or just reactivate the module? Could
>> somebody describe the design decisions and best practices to develop an
>> ows client? Who would be act as a mentor for those how want to contribute?
>>
>> Frank
>>
>> 2010/11/2 Roy Braammailto:roybr...@b3partners.nl>>
>>
>>  List,
>>
>>  the thread '*How to create BBOX Filter with FilterFactory2'
>>  *triggered me. I want to get the WFS module back to supported and
>>  TRY to support WFS 1.1.0. But i don't know where to start
>>  What's the status now?
>>  What needs to be done?
>>  Is there already somebody working on it?
>>  Can we form up some group of people to get this done?
>>
>>  Roy
>>
>>
>>  
>> --
>>  Nokia and AT&T present the 2010 Calling All Innovators-North America
>>  contest
>>  Create new apps&  games for the Nokia N8 for consumers in  U.S. and
>>  Canada
>>  $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>  marketing
>>  Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>>  http://p.sf.net/sfu/nokia-dev2dev
>>  ___
>>  Geotools-devel mailing list
>>  Geotools-devel@lists.sourceforge.net
>>  
>>  https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>>
>>
>> --
>> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
>> Create new apps&  games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>>
>>
>>
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
> - --
> wiki² - Softwareentwicklung
> Stefan A. Tzeggai, geb. Krüger
> Straßburger Weg 26
> 53113 Bonn
>
> email   tzeg...@wikisquare.de
> phone   0228 24 000 528
> mobile  0176 40 38 9559
> webpage wikisquare.de
> twitter http://twitter.com/geopublishing
> skype   alfonx
>
> reclaim your net - http://tor.eff.org
> enforce privacy - http://www.pgpi.org
> pgp key id: 51B576FD - http://pgp.mit.edu
>
> Please note that according to the German law on data retention,
> information on every electronic information exchange with me is
> retained for a period of six months.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzP7WQACgkQdFDQR1G1dv3ywQCfT8B/UTeB3QCo5JCBzFE05x35
> lGcAn2+8R08W8HAXkxeamtV6il9c05Z1
> =u4w8
> -END PGP SIGNATURE-
>
> 

Re: [Geotools-devel] How Much Interest in "Precise" JTS to SVG Conversion?

[Chris Holmes]

So you're not using Batik at all?  You're writing your own svg renderer? 
  Does it actual render?  Like take styling in to account?  If it can 
produced styled SLD, especially if it could stream the output, that's 
something we're interested in for geoserver, as batik is pretty slow.

On 3/5/10 11:38 AM, Sunburned Surveyor wrote:
> I'm getting close to my first release of some code that will allow
> BizzJUMP/OpenJUMP to export "precise" SVG. Currently OpenJUMP using
> Batik to export SVG. This makes it difficult to export geometry to the
> SVG coordinate system consistently, based on the same top-left page
> coordinate. My code will change that. The user will be able to convert
> JTS geometries to SVG using a specific top-left coordinate, scale
> factor, and rotation factor. I believe this code will greatly increase
> the ability to use BizzJUMP/OpenJUMP for cartographic purposes.
>
> Over time I hope to add support for things like Inkscape layers and
> SVG text generated from feature attributes.
>
> I'd like to know if there is any interest in this code among the
> GeoTools community. Because my code works directly with JTS, it could
> theoretically be used by any exisitng GIS application in Java that
> uses JTS to represent feature goemetires. It could also be used with
> other parts of Geotools to build a stand alone Shapefile to SVG
> converter.
>
> If there is interest in this code, I will start separating any
> BizzJUMP specific classes into separate packages and will adopt the
> Geotools file headers. I will then apply for an unsupported module.
>
> If there isn't enough interest, I'll just release the code through my
> SurveyOS SourceForge project. If you are curious, my current code can
> be found here:
>
> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/openjump_inkscape_svg_export/trunk/src/
>
> Landon
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-2905) Oracle Georaster support

[Chris Holmes (JIRA)]

Oracle Georaster support


 Key: GEOT-2905
 URL: http://jira.codehaus.org/browse/GEOT-2905
 Project: GeoTools
  Issue Type: New Feature
  Components: new modules
Reporter: Chris Holmes
 Attachments: GeoTools Oracle GeoRaster Configuration-1.doc, 
imagemosaic-jdbc.zip

I had a patch contributed to do Oracle GeoRaster support.  From the author:



  Here is a brief on the georaster capability:

1) It extends the imagemosiac-jdbc plugin
2) Can only be used to read already loaded georaster data. To load the data we 
used the java command-line tools available with Oracle Spatial
3) Developed against GeoTools 2.5.7
4) Utilises GeoRaster pyramid capabilities
5) Support 10g v1 & v2

We have a couple of issues:

1) how to re-distribute the GeoRaster Libraries which come with Oracle Spatial
2) OC4J Classloader issue with the required XMLParserV2.

I hope the fact it extends an already existing plugin isn't disappointing.  
What I can say though is that initial test result show that performance is very 
good, compared with an (unnamed!) commercial rival!



So the code may need to be cleaned up and adapted some, possibly as part of the 
jdbc-imagemosiac, or as a new plugin that extends it well.  But this should be 
enough to get people started.

Also attached is a .doc on how to configure it.

I have permission from the author and his boss to contribute it to open source.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ND Coverage-api on unsupported

[Chris Holmes]

See also 
http://docs.codehaus.org/display/GEOTOOLS/Multidimensional+Grid+Motivation+and+Scope

Jody Garnett wrote:
> A coverage (such as provided by the NetCDF format) that has more then
> row/col/band information. Often used to capture raster information
> that changes over time, or changes over height (forming a volume of
> voxels).
> 
> Does that mean that changes of time form chronxels?
> 
> In anycase you get the idea, we need to provide a few more parameters
> when getting back the band information (time or elevation in the two
> examples above).
> 
> Normally we deal with 2D raster information, because we don't know the
> "number" of extra dimensions for the data we give up and use the
> mathematical notion "N" for an nD raster.
> 
> Jody
> PS. perhaps Nixel? I like nixel
> 
> 
> On Wed, Dec 2, 2009 at 5:10 PM, Michael Bedward
>  wrote:
>> Hello all,
>>
>> At the risk of showing how slow and out of touch I am, could someone
>> explain what an ND coverage is or point me to some docs.
>>
>> Cheers,
>> Michael
>>
>> --
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> 
> --
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Question regarding gdal_retile.py

[Chris Holmes]

Simone Giannecchini wrote:
> Ciao Christian,
> a minor correction, there is no new API for Java, a few people,
> including somehow daniele has been trying to refine the SWIG api for
> more stability.
> 
> Now, about converting GDAL retiles to java, I am not 100 sure that we
> should try to convert the python code to Java right away, I have never
> been a fan of straight ports.
> Geotools, leveraging on imageio-ext should be able to most of the jov
> we need, or at least I would try and focus on removing the showstopper
> at this level rather than trying to focus on gdal java solely.
> 
> I think that if you have some time to dedicate to these matters we
> should try and integrate the various mosaic/pyramid pugins into one,
> as well as on making the import of mosaic/pyramid easier.
> 
> This is my 0,02 €.

I'll throw in my $0.02 with a big +1 to that, I've been thinking on 
these exact same lines.  You should be able to point at a directory and 
if you want it to automatically pyramid as well as mosiac you just turn 
on that option, have it happen seamlessly through GeoServer config.  The 
new automagic mosiac is super awesome, and would be super sweet if the 
magic extending to pyramiding as well.

> 
> Ciao,
> Simone.
> ---
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Founder - Software Engineer
> Via Carignoni 51
> 55041  Camaiore (LU)
> Italy
> 
> phone: +39 0584983027
> fax:  +39 0584983027
> mob:+39 333 8128928
> 
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://simboss.blogspot.com/
> http://www.linkedin.com/in/simonegiannecchini
> 
> ---
> 
> 
> 
> On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
>  wrote:
>> Since there is some interest in the utility (and a new tutorial, thanks
>> Simone), I think about a java port of the Python part of this utility.
>>
>> Second, on the gdal mailing list, there is some excitement about a new java
>> api for gdal.
>>
>> If, and only if, the java api is good, I can investigate in porting from
>> Pyhton to Java.
>> The advantage would be a better integration into geoserver/udig, making life
>> easer for our users and us :-)
>>
>> Your opinions
>>
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> 
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Switching to Java 6

[Chris Holmes]

Andrea Aime wrote:
> Chris Holmes ha scritto:
>> I think one thing we did in the past was put up a poll for users of 
>> GeoServer.  Might be nice to do that for users of 
>> geoserver/udig/geotools.  In general I don't want to leave anyone 
>> behind, and unless there's compelling reason to upgrade to 6 - new 
>> features that we don't get, I think it makes sense to stay compatible 
>> with 5.
> 
> Actually already started an informal poll on the users list,
> so far just one two answers, one pro and one cons, the cons one
> being a Websphere user in fact
> 

Yeah, I was thinking more of a web poll, with a blog post.  Maybe even a 
link from the home page.  Then more people would know about it, and 
would just have to click one button to make their opinion known.

> Cheers
> Andrea
> 

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] KML example

[Chris Holmes]

Note that GeoServer has done a lot of work on KML output.  We never put 
it in to GeoTools since no one ever asked about it, and a lot of it's 
ended up using GeoServer specific stuff.  But in general we're happy to 
have things migrate from GeoServer to GeoTools and can redo the license 
to be lgpl.  So if you're interested in taking the code and making it 
more generic for GeoTools let us know.

Michael Bedward wrote:
> Hi Justin and all,
> 
> Inspired by a KML question on the user list today I've added a simple
> KML writing example to demo/example...
> 
> http://svn.osgeo.org/geotools/trunk/demo/example/src/main/java/org/geotools/demo/xml/KMLExample.java
> 
> It runs OK but the method demonstrating feature collection -> KML
> produces many warnings like this...
> 
> WARNING: org.geotools.feature.defaultfeaturecollect...@b96738
> (org.geotools.feature.DefaultFeatureCollection)  is not of type
> org.opengis.feature.simple.SimpleFeature
> Nov 2, 2009 3:26:50 PM org.geotools.xml.impl.GetPropertyExecutor visit
> 
> The unit test class KMLParsingTest also generates these warnings.
> 
> Is there some way to avoid or suppress them ?
> 
> cheers
> Michael
> 
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Generalizing vector data

[Chris Holmes]

Interesting, I was just thinking along these lines, but doing the 
pyramid outside of GeoServer instead of inside, see 
http://sourceforge.net/mailarchive/forum.php?thread_name=49C94E81.40205%40opengeo.org&forum_name=geowebcache-devel

GeoServer would just need a generalization method, and then GWC would 
build up the pyramid - either on the fly or pre-seeded.  Could be 
interesting to bend it back around, so you could make the vector cache 
pyramid in GWC, and then use it back in GeoServer.  We're approaching 
similar things on the raster side as well.

Chris

Christian Müller wrote:
> Hi Michael, I am already using the JTS simpliefier. I am storing my features 
> in DB2, use the db2-ng module and have
> Features like 
> 
> BorderEurope
> BorderEurope_100 (Generalised 100 m)
> BorderEurope_1000 (Generalised 1000m) 
> 
> and so  on 
> 
> Andrea: 
> 
> The urgent need is WMS, but it should work for WFS too. Uisngthe SLD is a 
> possiblity, but
> this is not really transparent. At the moment I have to convince my users 
> that layout has to be done with SLDs and not
> downloding the whole stuff and working with ARCGis. Live is hard enough. 
> 
> My idea was to do a FeatureSource implementation containing the base feature 
> source and all generalisation feature sources,
> delegating most of the methods to the base feature source, but the problem 
> is that I need
> 1) the reqeusted Envelope
> 2) the pixelDimension
> to decide which generalisation to use. 
> 
> And I have no idea how to transport this information from the WMS GetMap 
> request to new FeatureSource implementation. 
> 
> A second brute force idea was to implement a geoserver plugin as described 
> here.
> http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn
> defining an own service to find the correct generalisation and do an WMS 
> redispatch.
> Nasty, but would work 
> 
> Any ideas
> christian 
> 
> 
> Andrea Aime writes: 
> 
>> Christian Müller ha scritto:
>>> Do we have something like pyramids for for vector data ?  
>>>
>>> What I mean is having a FeatureSource (say, the boundary of Europe having 
>>> 100 000 vertices) and drawing the boundary on a 640x480 image.
>>> I really do not need 100 000 points and therefore I make some 
>>> generalizations, each as its own feature source, minimizing io traffic 
>>> and cpu usage.  
>>>
>>> It would be nice to have a (read only) FeatureSource as a Wrapper for all 
>>> the generalizations (best design pattern would be a composite), which
>>> selects the proper generalization (depending on world and pixel size) and 
>>> returns a much smaller number of vertices.  
>>>
>>> It is the same concept as we have for image pyramids (I think, 
>>> AbstractGridCoverageReader has the logic built in).  
>>>
>>> Opinions ?
>> Are you talking WMS or WFS? WMS already does on the fly generalization
>> before rendering. And if you want to use pre-generalized data,
>> you can, just store multiple geometric columns in your database,
>> and use scale dependent rules to decide which geometry to use.
>> This effectively allows for using pre-decimated geometries, thought
>> of course it would be nicer if the datastore hid the extra columns
>> and could decide which one to pick automatically based on a generalization 
>> hint. 
>>
>> WFS wise, we're thinking to work on something like that as well.
>> WFS 1.1
>> specification allows to return not only attributes, but also
>> functions over attributes. At the moment they are not supported,
>> but we are looking into what amount of work it would take
>> to support them. Once that is working, we could have a
>> generalize(geom, distance) function that does generalization,
>> and also plays fully by the WFS rules. 
>>
>> Opinions?
>> Cheers
>> Andrea 
>>
>> -- 
>> Andrea Aime
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>  
> 
> 
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] GSIP 31 - Use Data Access API

[Chris Holmes]

Sorry to chime in even later.  A few thoughts

Ben Caradoc-Davies wrote:
> Andrea Aime wrote:
>> Ben Caradoc-Davies ha scritto:
>>> I have renamed the DataAccess proposal and now propose it as GSIP 31.
>>> http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API
>> The general idea in the GSIP is fine, but it's a very, very big
>> topic that requires changes in both GeoTools and GeoServer.
>> So I'd say we need a linked improvement proposal in GeoTools
>> as well, and a vote in both control commitees.
> 
> Preliminary investigations indicate that only small changes are required 
> in GeoTools. DataAccess/Feature/FeatureType (DAFFT), which is what I 
> mean by "DataAccess API", is already well-supported in GeoTools. 
> Furthermore, as a library with a decoupled architecture, GeoTools is 
> amenable to extension, so I can readily add new builders and 
> implementations without breaking backwards compatibility. The problem 
> with GeoServer is its centralised resource management, which has not yet 
> undergone the DAFFT transition to the same extent as GeoTools, and is a 
> blocker of future development. This is why the proposal is restricted to 
> GeoServer.
> 

So my main problem with this paragraph is the notion that the DataAccess 
API is 'well supported' in GeoTools.  Has it seen any real use in 
production?  Has it been integrated in stable versions of any projects?

The part of the switch that scares me is what happens after the classes 
have been changed over.  I've been a part of a feature model change and 
a data api change, and they are easy to do in GeoServer.  But the bitch 
is in the months after when lots of bugs pop up.

So I guess the assurance more needed from my end is that there are 
tasked resources that we can assign issues to and have them fixed as 
quickly as possible.  These will pop up probably until we hit 2.0.2.  I 
want to be sure that the job is not seen as done when the data access 
api is on, for me that's only the very start of the job.

> I anticipate that, at least for the first wave of changes, I may be able 
> to get by with changes to GeoTools as small as spot cleaning with a 
> little SimpleFeature Remover (TM). For example:
> http://jira.codehaus.org/browse/GEOT-2270
> 
>> The second thing that is required for any GSIP to pass (both
>> in GeoServer and in GeoTools) is resourcing.
>> As far as I know OpenGeo has agreed to only provide code
>> reviews for the changes that are going to happen, to make
>> sure we don't regress (too much) in the existing functionalities
>> while adding the new ones (and given the extensiveness
>> of the change, even only code reviews will take a lot
>> of time on our part, which means a significant financial
>> investment anyways). Anyways, I'm not the one paying the
>> bills on this one, Chris might want to chime in here ;-)
> 
> I would be delighted if OpenGeo:
> 1. Review the patches.
> 2. Run CITE tests.
> 3. Decide if performance is sufficient and no regressions are introduced.
> 4. Commit the changes.
> 5. The same ongoing support that is already provided.
> 
>> Do you have enough resources to pull this up on your own?
> 

All these are fine except I'm not sure on #5.  If this introduces a 
bunch of bugs that no one is helping us fix we'll look in to backing out 
the changes.  But that can easily be seen as much more support than we 
already supply.  We are obviously willing to help fix a few bugs 
introduced, but we don't want to be left as the maintainers of a massive 
new work.

It doesn't sound like this is what you're saying, it sounds like you are 
committed to help out for the indefinite future.  But I just want to be 
clear.  We will be looking at the patches more closely than others since 
they are core and cut across everything, and no matter what will 
introduce bugs.  I wish our testing was good enough to catch most all of 
the potential bugs immediately, but it's not.


> I believe so. I am now working full-time on this task. It is essential 
> for the success of my project that this work be completed. We can add 
> more developers if required, although it is my preference that they 
> continue on other areas (e.g. GeoTools app-schema).
> 
When does funding on your project end?  And are you able to task people 
on helping fix bugs until that time?


I apologize if any of this comes across as negative, it's really just us 
evaluating risk and trying to minimize it as much as possible.  This 
will be a great improvement for GeoServer, and we're excited to grow the 
community.

best regards,

Chris

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Re: [Geotools-devel] looking for a theme for my master thesis

[Chris Holmes]

better than 1 but still not yet quite
>>satisfying. If give just one number (the temperature in our
>>example) while we would like to have some estimation of its
>>uncertanties. A value inferred in such indirect way from other
>>parameters is less "certain" than a direct measurement of Sea
>>Surface Temperature. Bayesian network may be a solution (but
>>I'm probably out of scope of a master thesis here). 
>>
>>I used "Sea Surface Temperature" vs "Sea Level Anomaly" above as
>>a real-world example (with real applications on our side), but
>>such a project would actually be against any arbitrary set of
>>geophysics parameters. 
>>
>>  
>>
>>
>> Proposal Number #2
>> --- 
>>
>> Same goals than above, but working on a single image without any attempt to
>> leverage the correlation between geophysics parameters: 
>>
>> http://sprott.physics.wisc.edu/pubs/paper276.htm 
>>
>>
>> Is it the kind of suggestions you were looking for? 
>>
>>  Martin
>  
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Moving the repository to OSGEO

[Chris Holmes]

+1

On Mon, Nov 3, 2008 at 5:38 PM, Ben Caradoc-Davies
<[EMAIL PROTECTED]> wrote:

> Andrea Aime wrote:
> > It's enough positives to make it a decision, but on
> > such a move consensus is better.
>
> +1 from me.
>
> --
> Ben Caradoc-Davies <[EMAIL PROTECTED]>
> Software Engineer, CSIRO Exploration and Mining
> Australian Resources Research Centre
> 26 Dick Perry Ave, Kensington WA 6151, Australia
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Oracle datatore, the SDO classes

[Chris Holmes]

Jody can answer this more fully, but as I remember they had a client who 
wanted to not rely on the Oracle java spatial jars.  I believe there 
might have been some uncertainty at the time over whether oracle was 
going to continue to support that method of access.  I think more 
recently we got feedback that we probably should just use them, instead 
of trying to maintain our own SDO classes.  Though I personally had to 
do a lot of small bug fixes, copy and paste errors on the like, so at 
this point those classes should be pretty solid.


Chris

Andrea Aime wrote:

Hi,
I'm trying to understand a little thing about the
existing Oracle data store. Why the SDO classes
were written in the first place? I mean, Oracle
provides JGeometry and the dummy jar seems to
cover it, so what was the reason to create the
a separate implementation?

Cheers
Andrea

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Feature paging proposal created, please discuss

[Chris Holmes]

One slight bit of feedback, on naming - is 'offset' the name that the 
element in WFS 1.2 Query is going to be?  I think many of the other 
properties of Query are taken from the WFS spec, so it might be nice to 
have this also be in line with it.  I couldn't find the wfs 1.2 spec, 
even in the members section, but you could just ask Peter what the 
property will be.  Of course it's not a huge deal at the geotools level, 
but we should figure it out for the geoserver level.


Other than that the proposal looks great.

Chris

Andrea Aime wrote:

Hi,
I've written down a first version of the Feature paging  + query 
capabilities proposal as a base for further discussion:

http://docs.codehaus.org/display/GEOTOOLS/Feature+paging+and+Query+capabilities

(If you did not hear about it, it basically tries to add support
for paging thru features in a datastore and also tries to add
support for query capabilities as a way to state what parts of
query are supported, and what aren't).

The proposal is not finalized, thought seems like a good starting
point for discussion. Please provide feedback.

Cheers
Andrea

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,480640ec45493668746562!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GSoC

[Chris Holmes]

Yeah, GeoTools will do summer of code.  Not sure we have a page on 
GeoTools yet.  You can add it to the geoserver page: 
http://geoserver.org/display/GEOS/Summer+of+Code+2008 and we can port 
the appropriate ideas to GeoTools, indeed it might be good to list some 
in both places.  We will do SoC as part of OSGeo, which I think we have 
a very good chance of getting since we did it last year.  If you have 
other ideas that make sense at the geotools level feel free to throw 
them in.  If we have a nice 52n wps/geoserver integration task we could 
put that as part of GeoServer as well.


Chris

Bastian Schäffer wrote:

All,

the 52North Geoprocessing Community is going to apply for the google 
summer of code. By collecting ideas, we thought about that it would be 
nice if there would be some kind of KML --> geotools converter. As Chris 
Holmes told us, that at least geoserver has a geotool --> KML writer, 
but no reader. This would allow the use of KML in chaining scenarios as 
input and ouput fo e.g. WPS. Because this is more geotools related than 
it is 52North, we just want to know if you have thought about this? Are 
there any plans to implement that or are you guys also applying for the 
GSoC? I think this would be a nice little project which has some applied 
relevance for our WPS project but would fit better into your proposal. 
Nevertheless, I would be willing to supervise this from our side.


Regards,
Bastian Schaeffer

52°North

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47d557d192131336712104!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposed change of org.geotools.tile

[Chris Holmes]

Interesting, I didn't realize that org.geotools.tile exists.

It might be really good to reconcile the implementation in geotools with 
what Arne's done in GeoWebCache, so we can reuse code.  All our work we 
like to get in geotools if there's the potential for wider reuse, but I 
wasn't aware there was already work done on this.  I'm not sure if it's 
appropriate to reuse everything, but it'd be nice to at least use the 
same code to access alternate tile servers.  Also note that we've got 
'metaTiling' code in GeoWebCache, leveraging JAI, which can make for 
some nicer looking tiles.  Arne should be able to tell you more and 
figure out how best to collaborate.


best regards,

Chris

Jody Garnett wrote:
Sounds good, I am the module maintainer for unsupported/tile if you have 
any questions please ask.


You should find the code base organized to allow:
- alternate TileCache implementations to be substituted (although 
perhaps we need to make a plug-in mechanism?)

- additional "tile" servers

We may find it worthwhile to talk to the JAI Gurus on this list at a 
later stage - they could hook us up with the JAI Tile Cache etc...


In the broader scheme of things we should make a specific MapLayer 
implementation for the MapContext data structure and allow

the GeoTools renderer to make use of these services.

For my part I would like to make a implementation that talks to MapGuide 
Open Source; so GeoServer could hang out the front end and offer a good 
WMS implementations on top of it.


Jody

Hi everyone,

the module org.geotools.tile currently has an implementation for
accessing the NASA World Wind server and an implementation of a
SimpleTileCache, which caches only the result of the last query.

We would like to add support for WMS-C [1]. Server implementations are
available from MetaCarta [2] or from GeoWebCache [3]. 


Additionally we want to create at least two tile cache implementations
(MemoryTileCache and DiskTileCache). It should be possible to configure
the size of the cache (number of tiles to be cached) and to plug-in a
cache algorithm like Least Recently Used, Least Frequently Used, or
maybe Adaptive Replacement Cache. Caches can be used in a cache
hierarchy.

Are there currently and other activities in that area that we should be
aware of? Are there any ideas oder suggestions from you?

Regards,
  Holger


[1] http://wiki.osgeo.org/wiki/WMS_Tiling_Client_Recommendation
[2] http://www.tilecache.org/
[3] http://geowebcache.org/

---
Holger Jaekel
phone: +49 (89) 121528-75   mailto:[EMAIL PROTECTED]
fax:   +49 (89) 121528-79   http://www.gaf.de   
GAF AG Arnulfstr. 197 80634 Muenchen Germany

Vorstand: Dr. Peter Volk, Aufsichtsratsvorsitzender: Marcello Maranesi

Amtsgericht Muenchen HRB 140 509, Firmensitz: Muenchen


  


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47c8509a298961030819293!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] IRC breakout meeting for FeatureAccess proposal

[Chris Holmes]

Hey, I haven't fully absorbed all the issues, but I did skim over the 
irc logs, and thought I'd comment on one thing.


I don't think it's worth doing backflips to maintain backwards 
compatibility at this point in time.  We're already breaking the api 
with the SimpleFeature change.  If we'd already released that then I'd 
be really hesitant to do anything to break backwards compatibility. 
Users of GeoTools are already going to have change their code.  If we 
have an API that we like better now is the time to use it, even if 
there's another slight change.  And I'm one who's really against 
breaking backwards compatibility, but in this case I don't think it 
needs to weigh on the decision much as long as it's something small and 
sensible.


I'm not favoring one proposal or another, I haven't really read 
everything.  I'm just saying as a criteria for deciding I wouldn't place 
backwards compatibility very high at this point.


best regards,

Chris

Gabriel Roldán wrote:

Breakout meeting time, anyone that want to join please do at #geotools.

Cheers,

Gabriel
On Wednesday 06 February 2008 06:57:19 pm Gabriel Roldán wrote:

Hi all,

As stated in the previous message the proposal is ready for your
evaluation.

I'm calling for a breakout IRC meeting to discuss it, as agreed at
yesterdays geoserver irc meeting.

The proposed date and time is Feb. 7th, 2007: 17:00 UTC


That time seemed to work for most of us at yesterday's meeting, yet acuster
already told he wouldn't be able to attend.

Feel free to raise your concerns if you can't too so we can arrange for a
different time/date, though keep it mind it'd be nice to sort it out over
this week.

Best regards,

Gabriel.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel






-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47ab3975249282458217002!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

[Chris Holmes]

Sounds great, thanks a ton Martin for all the help with the referencing 
stuff, it sounds like it's all fixed.  So as soon as we get out GeoAPI 
2.1.0 we can release GeoServer 1.6.0.  Let me know if there's anything 
we can do to help out with the GeoAPI release.


best regards,

Chris

Martin Desruisseaux wrote:

Andrea Aime a écrit :

1) We still depend on geoapi 2.1-rc1. Did any other change occurr
in that geoapi branch, of can rc1 be re-released as 2.1 final?


Just posted an email on GeoAPI mailing list. I did a "svn diff" and the only
change is synchronization lock in CodeList.valueOf(String) methods. There is no
API change. So I suggest to do the release for the 2.1 branch.



3) We still need to re-run all of the cite test suites
in GeoServer to make sure that no other bugs popped up lately
(and this must be done before releasing 2.4.0)


If we get the okay on the mailing list, I will process to GeoAPI 2.1.0 release,
so the CITE tests can be run with GeoAPI 2.1.0 final.

Martin

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47aad50690811096210785!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Sanity on trunk; was report on grid coverages

[Chris Holmes]

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 geoserver codesprint, and indeed there's no 
way it could be with the amount of collaboration we do at the geotools 
level.  We may try to piggyback on a general OSGeo sprint, but even if 
we don't we'd still want to try to get uDig folk and general GeoTools 
people there.  And you could completely work on whatever is your 
priorities at the time.  So I guess I don't consider not looking at 
geoserver in several months a good enough excuse ;)


Chris



All the best,

--adrian






On Mon, 2008-02-04 at 01:42 +0100, Simone Giannecchini wrote: 

On Feb 1, 2008 7:21 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:

Jody Garnett a écrit :

a) the api changes that are happening; is this part of the expected long
term GeoAPI plan? (if so it would fall outside our proposal page process)

No, this views stuff (geophysics, packed, etc.) do not appear at all in GeoAPI.
They do not appears in any OGC/ISO specification I'm aware of. I don't plan to
bring that stuff in GeoAPI since I suspect that it would be highly controversial
(it is already in GeoTools alone).

This stuff exists only because I try very hard to conciliate two worlds:

  - data as floating point values in geophysics space.
  - video cards (through Java2D) which work best with
integer values in RGB space.

How would you classify data like GTOPO30 and GTOPO60 which are
elevation data, 16 bits unsigned where the No Data values is -?
Or DTED (Military Elevation Data) which are as well 16 bits unsigned,
or SRTM () which are signed integers elevations that can range from
-32767 to 32767 meters, encompassing the range of
elevation to be found on the Earth. Nodata are flagged with the value -32768.
This data cannot be visualized directly, but they would not even be
strictly "geophysics", moreover there is no specific colormap to apply
and also there is a Nodata value which is an integer and not NaN.


This is controversial for good reasons, but I try very very hard to preserve the
geophysics meaning of images, otherwise the whole coverage module would become
pointless to me (even if RGB images have a lot of values for other users, I'm
not myself in those fields. This explain why RGB support was poor in the first
place).


I think that nobody ever suggested id to remove the concept of
geophysics but rather to not base the whole coverage module on that
concept.




b) I noticed trunk depending on GeoAPI 2.2-SNAPSHOT; is this correct or
is there a GeoAPI 2.3-SNAPSHOT we should be using

Yes it is correct. There is no GeoAPI 2.3 as far as I known?

The pending API change in GeoAPI coverage are about replacing the old OGC 01-004
specification by ISO 19123. This is yet an other topic. The geophysics /
photographic / packed views issues is unrelated to either OGC 01-004 and ISO 
19123.



Martin I think you are stressed out on a deadline are you not? Can I
help set up the proposal page for you ... it will at least let me catch
up on all this email.

We just created the following page:

http://docs.codehaus.org/display/GEOTOOLS/Improve+support+of+RGB+coverages

but this is just a skeleton for now (we are just starting the work on wiki side
- I admit that this is a very late stage).

Better later than never :-). Anyway it would be great if you could
start to write something about what your proposal would be, I think
that wass the original purpose if this
http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal.

Ciao,
Simone.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
---
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:  +39 0584983027
mob:+39 333 8128928


http://www.geo-solutions.it

---

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel



-
This SF.net email is sponsored by: Microsoft
Defy al

Re: [Geotools-devel] Report on what is going on with grid coverages

[Chris Holmes]

Martin Desruisseaux wrote:

Side note in case peoples wonder what is going on with recent work on "Resample"
operation.

1) The way I designed the coverage module a few years ago, I did not recognized
   the need for "photographic" image. To me a coverage is a matrix of geophysics
   values (sea surface temperature, elevation, electromagnetic signal, etc.) and
   handling them as RGB images was seeing wrong. My radical point of view was
   "if it doesn't have any physical meaning then it has nothing to do in a GIS".
   I intentionnaly did nothing for making RGB support easy. However one or two
   years ago Simone convinced me that we need real support for RGB images, but I
   never had the time to bring first-class support for them in the coverage
   module. What have been done up to date (color model expansion, etc.) are
   basically workarounds.

   Now I'm trying to provide real support. This means replacing
   GridCoverage2D.geophysics(boolean) by GridCoverage2D.view(ViewType) where
   ViewType is an enumeration including GEOPHYSICS, PACKED and PHOTOGRAPHIC
   among others. This support will not be completed soon, but pieces are
   slowly falling in place. There is an unfortunate risk that I break some
   Geoserver code without noticing, but will try to fix rapidly.


Cool, thanks for the heads up.



2) Looking at the GeoServer WMS output, I have the feeling (but did not
   verified) that GeoServer performs at least some of its calculation on the RGB
   values, doing color expansion even when the data were originally geophysics.
   I would like to remind that it may produce "nice looking" image, but the
   colors that you get that way are wrong - not the ones you would get if the
   calculation was performed on the real geophysics values. However I suspect
   that GeoServer do so for performance reason and for working around some
   complication in geophysics calculation. 


My impression is that WMS is all about the 'nice looking' image, if you 
want the real scientific values you should be using the WCS.  I admit a 
good bit of naivety on this, but it seems to make sense, you get the WFS 
or WCS when you care about the completely accurate thing, you use the 
WMS when you want a mapping image to use on the web, and you probably 
want it as fast and nice looking as possible.


Chris

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] How to move off EPSG-WKT

[Chris Holmes]

Oh, my bad, I didn't realize we were using epsg-extensions.  I guess I'd 
still prefer to have it unsupported, but if it doesn't build at all and 
there have been proper warnings I suppose it may be ok.


C

Adrian Custer wrote:

Hey Chris,

As I understand it, the epsg-extensions module exists *exactly* to
enable a way for users to define CRS's other than those defined by EPSG.
Does this module not work for you?


You are right, perhaps my desire to cleanup is misplaced. I merely note
the regular user questions which arise because it's easy to have both
wkt and epsg in the distribution and that causes user problems. And
keeping an outdated text version of the EPSG database seems like a
really bad idea: any user who needs it would be better off getting the
newest parameters from EPSG and regenerating the best current
parameters.

The cleanup comes in 2.5 (trunk) since the factory class has been
deprecated in 2.4. Users get a full cycle to change their code (although
with the great factory system it's true they may not know if we don't
warn them LOUDLY in the 2.5 release notes.

--adrian


On Wed, 2008-01-30 at 16:59 -0500, Chris Holmes wrote:
You're deleting the epsg-wkt module entirely?  I think it's great that 
the whole codebase works with epsg-hsql, but I don't think that's reason 
to remove epsg-wkt.


We're primarily on epsg-hsql on GeoServer, but we actively use epsg-wkt 
to allow people to add custom projections.  Doing so is close to 
impossible with epsg-hsql.  See 
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver+1.5.0+(onwards)


vs.

http://docs.codehaus.org/display/GEOSDOC/Hacking+the+EPSG+hsql+database+directly

I also don't understand this 'clean-up' desire, it's pretty dangerous to 
just delete things that geotools users may rely upon.  We have an 
'unsupported' module to move things that we don't want to support any 
more, I think it'd be fine to move epsg-wkt there, but deleting it 
entirely seems a bit much.  Just because you're no longer using it 
doesn't mean that no one else is.  We have no desire to switch to epsg 
only, wkt is a much better way for users to add projections.


Chris

Adrian Custer wrote:

Hey all,

I spent the afternoon trying Geotools with epsg-hsql only. Seems like
everything works! We have a minor test failure against a method in the
WMS module but that method is actually wrong *and* inefficient so I
imagine we'll fix it.

What's the feeling of switching trunk over? 


We could change all the pom's and hammer the result for a week then
delete epsg-wkt (trunk only)! 


Would doing this next week work without interfering with your schedules?
Hopefully, we can confirm this at the IRC but if you are not going to be
there, let us know if this could interfere with your releases or other
work.

--adrian


Jody, was going to answer you but Martin beat me to it. Good thing too,
since he is your man for all your referencing module questions. 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel






!DSPAM:4005,47a0f77e85622143011171!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] How to move off EPSG-WKT

[Chris Holmes]

You're deleting the epsg-wkt module entirely?  I think it's great that 
the whole codebase works with epsg-hsql, but I don't think that's reason 
to remove epsg-wkt.


We're primarily on epsg-hsql on GeoServer, but we actively use epsg-wkt 
to allow people to add custom projections.  Doing so is close to 
impossible with epsg-hsql.  See 
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver+1.5.0+(onwards)


vs.

http://docs.codehaus.org/display/GEOSDOC/Hacking+the+EPSG+hsql+database+directly

I also don't understand this 'clean-up' desire, it's pretty dangerous to 
just delete things that geotools users may rely upon.  We have an 
'unsupported' module to move things that we don't want to support any 
more, I think it'd be fine to move epsg-wkt there, but deleting it 
entirely seems a bit much.  Just because you're no longer using it 
doesn't mean that no one else is.  We have no desire to switch to epsg 
only, wkt is a much better way for users to add projections.


Chris

Adrian Custer wrote:

Hey all,

I spent the afternoon trying Geotools with epsg-hsql only. Seems like
everything works! We have a minor test failure against a method in the
WMS module but that method is actually wrong *and* inefficient so I
imagine we'll fix it.

What's the feeling of switching trunk over? 


We could change all the pom's and hammer the result for a week then
delete epsg-wkt (trunk only)! 


Would doing this next week work without interfering with your schedules?
Hopefully, we can confirm this at the IRC but if you are not going to be
there, let us know if this could interfere with your releases or other
work.

--adrian


Jody, was going to answer you but Martin beat me to it. Good thing too,
since he is your man for all your referencing module questions. 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47a0ea5064701849620573!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Introducing new Geoserver developer @ CSIRO, Ben Caradoc-Davies

[Chris Holmes]

Also could you give more info on 'procedures as WFS functions'?  I'm 
definitely intrigued, it sounds like it could have some awesome 
possibilities, like the routing that you mentioned, but I'm having 
trouble thinking on how it would actually work.  Could you maybe throw 
up an RnD wiki page with a few examples.


best regards,

Chris

[EMAIL PROTECTED] wrote:

Hi all,

just a quick note to introduce Ben Caradoc-Davies at CSIRO in Perth, Australia, who 
will be working on reference implementations of web services against data models, 
especially the GeoSciML and Observations & Measurements standards.

Ben will be working with my support, to address the huge backlog of things I've 
failed to find time to fix and polish as I've worked with Gabriel to get 
community-schema support core functionality to a point where it functions.

We will be developing project plans, and these will be made visible via Jira 
for anyone else who wants to play.

We have some short-term objectives with regard to supporting GeoSciML - in 
particular keeping test cases up to date, performing regression tests as the 
rest of the 2.4/1.6 codebase changes, but a few new bits:

* support for procedures as WFS functions
* WMS support against complex features (will build a wms-c to sit alongside 
wfs-c in community space for now, but we're keen to test the capabilities of 
trunk as it emerges)
* testing community schema support against various back-end (postgis, 
shapefile, oracle etc)

Ben has already highlighted some issues with the sure-fire plugin and wants to 
recommend a version upgrade to fix some bugs, and we'll work in the short term 
by providing patches to Jira tasks, but we hope to establish committer status 
and in particular take over maintenance tasks in the community-schema modules 
so Gabriel can focus any cycles he has in the migration path to trunk, and in 
the meantime we can test and demonstrate the capabilities.

Rob Atkinson









-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,4799d1fe14071804284693!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Introducing new Geoserver developer @ CSIRO, Ben Caradoc-Davies

[Chris Holmes]

That's great new!  Welcome Ben.

I am curious though how much sense it makes to maintain the community 
schema stuff on its branch versus doing the work to migrate to trunk. 
We've got trunk with the new complex feature model now, and we're going 
to start to have the GML3 reader parse in to it and hook it up to the 
renderer.  If your work is done against that then it will slide right in 
to supported status, instead of having to do a big change over at once.


I haven't been following closely enough to know if that makes sense, but 
we did do a bunch of work to get the new feature model in to trunk, and 
one of the main reasons TOPP took on that contract was the opportunity 
to improve things for community schema type things and make them 
possible as an integrated part.


best regards,

Chris

[EMAIL PROTECTED] wrote:

Hi all,

just a quick note to introduce Ben Caradoc-Davies at CSIRO in Perth, Australia, who 
will be working on reference implementations of web services against data models, 
especially the GeoSciML and Observations & Measurements standards.

Ben will be working with my support, to address the huge backlog of things I've 
failed to find time to fix and polish as I've worked with Gabriel to get 
community-schema support core functionality to a point where it functions.

We will be developing project plans, and these will be made visible via Jira 
for anyone else who wants to play.

We have some short-term objectives with regard to supporting GeoSciML - in 
particular keeping test cases up to date, performing regression tests as the 
rest of the 2.4/1.6 codebase changes, but a few new bits:

* support for procedures as WFS functions
* WMS support against complex features (will build a wms-c to sit alongside 
wfs-c in community space for now, but we're keen to test the capabilities of 
trunk as it emerges)
* testing community schema support against various back-end (postgis, 
shapefile, oracle etc)

Ben has already highlighted some issues with the sure-fire plugin and wants to 
recommend a version upgrade to fix some bugs, and we'll work in the short term 
by providing patches to Jira tasks, but we hope to establish committer status 
and in particular take over maintenance tasks in the community-schema modules 
so Gabriel can focus any cycles he has in the migration path to trunk, and in 
the meantime we can test and demonstrate the capabilities.

Rob Atkinson









-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,4799d1fe14071804284693!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] caching?

[Chris Holmes]

Yeah, I wouldn't worry too much about this requirement, I've been 
thinking about it a bit and I think we could do some decent stuff at the 
datastore level.  Like a caching datastore could just take two other 
datstores - the source (likely a wfs or some other remote one) and the 
local.


The goal of caching WFS would be to be able to make use of different 
strategies that are particular to a WFS.  Things like the 
geosynchronization work, which is looking like it'd be a georss feed 
notifying on what has changed, or leveraging http cache control headers 
(though this won't so much work with wfs, needs an atom type thing).  Or 
client controlled caching, like expire after a certain amount of time, 
or when the user asks for a reload.  But yeah, I think we should be able 
to design something later that covers several use cases, and could work 
with different datastores that might have different ways of notifying 
about cache expirations.  We can later gather some use cases and make an 
informed design.


Chris

Gabriel Roldán wrote:

Hi,

so one requirement for this DataStore is to be "caching friendly".
Yet, though doing some caching strategy specific for it, I've always thought 
of a "cached" datastore as a cross-cutting concern, and both Andrea's 
original thoughts [1] as well as Christophe Rousson's summer of code work [2] 
seem to share that conception.


So I guess I'm not going to do anything in particular to support caching. I 
think as long as a DataStore properly implements feature events would be a 
good candidate to be wrapped by caching one. It also makes sense for the 
client application to decide which of them deserve to be cached and which 
not.


Another possibility would be to supply the DataStoreFactory some sort of 
implementation hint to, for example, signal the datastore to plug into a SPI 
discoverable cache. But, I'm not sure this is a good usage of hints.


thoughts?

Gabriel

[1] 
[2] 

On Thursday 10 January 2008 06:15:39 pm Jody Garnett wrote:

Gabriel Roldán wrote:

If this seems ok, it'd imply moving some stuff around on the wfs plugin,
mostly some package refactoring to isolate version specific code from
general one. In my opinion it shouldn't be a problem as its the DataStore
nature not to be API, and the only public class should be the datastore
factory.

This is the same approach we took for OWS-3 you can find an example of
how to subclass WFS1.0 datastore
and override just enough methods for GML3 parsing.

The code is still available in svn here:
- http://svn.geotools.org/udig/branches/ows3/gt/owswfs/

While you are there see if you can make a public method for
getCapabilities() it is one of the main reasons we still
subclass WFSDataStore in uDig :-)

This may be obvious but the approach to take is make a strictly 1.0
datastore and a 1.1 specific datastore and let the
WFSDataStoreFactory do the version negotiation in order to choose the
correct version. You will find ShapefileDataStoreFactory
takes the same approach when choosing between ShapefileDataStore and
IndexedShapefileDataStore.

Cheers,
Jody






-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,47868dea225621137850744!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Geotools LEGAL: A vetted draft

[Chris Holmes]

Awesome, thanks for taking this on Adrian.  I'm happy to liaison with the
board on this, I believe there should be a meeting relatively soon.  We
just need the board to approve it as a document that can be used by
projects?

Chris

On Sat, December 29, 2007 4:11 am, Adrian Custer wrote:
> Hey all,
>
>
> Heather Meeker gave us a present for the new year! We have a draft
> copyright assignment agreement which you can see at:
>
> http://docs.codehaus.org/download/attachments/9765352/010-GtCopyright-HJM
> version_FINAL.odt
>
> as an attachment to the Geotools Copyright Assignment wiki page
>
> http://docs.codehaus.org/display/GEOTOOLS/Geotools+Legal+Review
>
>
> for your reading pleasure. I think it does everything we want it to do.
> Comments are welcome; formatting issues can be dealt with later.
>
>
>
>
> Going forward, we need to:
>
>
> 1) Get the OSGeo board to agree to the text.
>
>
> Presumably this needs to be brought up as a disscussion
> item to an OSGeo board meeting. Chris Holmes, are you willing to take this
> on since you were willing to run liaison between us and the Board?
>
> 2) Reach, among ourselves, a consensus path for Geotools
> copyright.
>
> Our choice will be either to use this document to give
> the copyright to OSGeo or to use the 'Fiduciary License Agreement' (see
> http://www.france.fsfeurope.org/projects/ftf/fiduciary.en.html
> ) to give the copyright to the FSFeu, if they will have
> us. The former gives us a tighter integration into OSGeo, the latter may
> give us a stronger legal backing. We can have that discussion in a
> structured way in January.
>
>
> The best we can hope for is to give one organisation
> most of the copyright to the code since some past authors have already
> stated they will not sign any agreement. For future contributions, we can
> decide if we want to force or merely recommend that authors sign the
> document.
>
> 3) Do all the grunt work to GRADUATE.
>
>
> Get the document signed by as many people as possible,
> change the headers, slave under Jody's direction to redo the provenance
> review, bleed, cry and commit.
>
> cheers, --adrian
>
>
>
> !DSPAM:4005,477610e3116982143011171!
>
>
>


-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] SLD Editor status

[Chris Holmes]

It didn't go super far.  It was also ajax based.  It more just was a 
nicer way to edit the text, less so a real visual thing.  We're looking 
for funding for an ajax/openlayers based sld editor, perhaps if we get 
that started you could collaborate on that.  There are some others who 
are also working towards similar ends.  Would you be interested in that, 
or just in something in swing?  Which is not to discourage you from 
doing a swing one, that could be quite nice.


best regards,

Chris

Stefan A. Krüger wrote:

Dear Developers

I woud love to see a cool stand alone SLD Editor with Swing+Geotools. and i
might have some time to work on it next spring. i have seen talk about
the GSoC project and its accepted:
http://docs.codehaus.org/display/GEOSDEV/GeoServer+Summer+of+Code+Ideas#GeoServerSummerofCodeIdeas-StyleEditor

How is the project going? I want to get me in touch of the guy who does it.. I 
would like to cooperate on this.


Greetings
Steve

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Away for Mondays Meeting

[Chris Holmes]

Martin Desruisseaux wrote:

Jody Garnett a écrit :
Hi Guys; I am on the road for Mondays meeting; I will be sure to check 
the logs. In related news I did not make it to the OSGeo board meeting 
(bad jody no cookie) for which I apologize.


No problem, I missed a lot of GeoTools meeting myself. But just for information,
did we had an other Geotools representative at the OSGEO meeting (Cameron, Paul
or Chris for instance)?

Paul and I were there, but we also had Adrian show up, who did a much 
better job with GeoTools concerns than either of us could have.


We have some forward progress, got to the bottom of a pretty big 
miscommunication - I didn't realize that I actually had authority to 
grant the use of OSGeo lawyer time to GeoTools.  When Frank stepped down 
he told me I did, and I somehow just missed it . So I apologize to 
everyone for my role in messing up the process.


So now Adrian is going to send me the stuff to send to Heather, and I'll 
get them talking directly and hopefully will reach a document we all like.


best regards,

Chris



Martin

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,472de1bb251972085621377!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Alternate logging factory proposal ready for voting

[Chris Holmes]

Andrea Aime wrote:

Chris Holmes ha scritto:


Andrea Aime wrote:

Chris Holmes ha scritto:

Ok, I'm trying to get a handle on this issue.

One question, what's the objection to just using SFL4J ?

It seems to meet Justin's criteria of using a standard library, it'll 
work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot 
better than commons logging.


I imagine I just missed what the objection was, but I'm curious to 
hear it.

sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing 
redirections is to implement exactly the same classes in the different

jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right?  Why would we 
want to force it?


You must have lost some episodes of the logging saga :)
GeoServer is using log4j since Saul switched GeoServer to use it,
and 1.6 configures the logging levels using log4j configuration files.
So yes, either 1.6 uses log4j or it has no control on the logging levels
whatsoever.
Ah, right.  Yeah, I missed that episode.  Ok, just ignore me, I have 
nothing productive to add :(


In the unproductive vein, however: 'this stuff sucks!'  And thank you 
all for doing your best to figure out a solution that works.


Chris


It's just that at the moment we're using the java logging api, which
redirects to commons logging, which redirects to log4j, and the
logging level setup is simply not working.

Cheers
Andrea

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,4727795931781431913854!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Alternate logging factory proposal ready for voting

[Chris Holmes]

Andrea Aime wrote:

Chris Holmes ha scritto:

Ok, I'm trying to get a handle on this issue.

One question, what's the objection to just using SFL4J ?

It seems to meet Justin's criteria of using a standard library, it'll 
work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot 
better than commons logging.


I imagine I just missed what the objection was, but I'm curious to 
hear it.


sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing 
redirections is to implement exactly the same classes in the different

jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right?  Why would we 
want to force it?




I guess the second problem is timing, the slf4j is different enough
from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
manual changes will have to be performed manually instead of using
a single search and replace, especially in the modules managed
by Martin.


Hmmm...  Let's see what he says.
What about GeoServer using sfl4j and geotools continue to use java 
logging?  Would that help solve things?


Chris


Cheers
Andrea

!DSPAM:4005,472776d522262143011171!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Alternate logging factory proposal ready for voting

[Chris Holmes]

Ok, I'm trying to get a handle on this issue.

One question, what's the objection to just using SFL4J ?

It seems to meet Justin's criteria of using a standard library, it'll 
work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot better 
than commons logging.


I imagine I just missed what the objection was, but I'm curious to hear it.

Chris
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do the PMC care to vote on the latest DataStore.close() proposal?

[Chris Holmes]

+1

Ian Turton wrote:

On 10/19/07, Andrea Aime <[EMAIL PROTECTED]> wrote:

Hi people,
sorry to try to hurry you up, it's just that I'd like to have this
one in in time for GeoServer 1.6.0 beta4 (which will be released
early next week).



+1 - sorry missed that I was supposed to be voting for this.

Ian
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Sprint location tomorrow

[Chris Holmes]

In case people are wondering and not wanting to figure out the location 
on their own, it's at the west ballroom in the Harbour Towers Hotel - 
http://www.foss4g2007.org/program_overview/friday/


Starts at 9am, lunch provided.

Map at http://tinyurl.com/2eh8h7

C
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] feature cache demo

[Chris Holmes]

Cool, this looks like it could be used.  Do you have design docs 
somewhere?  Apologies I haven't been paying more attention to this.


A few questions, though I'm completely fine if the answer to them is to 
just look at the docs.  I found 
http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data


Did you implement the cache yourself, or are you leveraging existing 
caching projects like OSCache and JBoss cache and the like?  If you're 
not, would it be possible to use one of those?  Ideally one could use 
your cache with an existing cache that's set up?


How far in your plan did you get?  Do you have a disk caching datastore? 
 Does it have an LRU eviction strategy or anything like that?  Like 
from memory to disk to completely out?


Do you handle transactions?  Like if I do a transaction does it pass to 
the main datastore and update it and expire the cachingdatastore's value?


If you've got disk working, how are you storing the features on disk?

Did you get the offline mode stuff working?  I've been thinking about 
such things, but more with regards to a WFS datastore that does good 
caching.  But could potentially reuse some of your code.  There may be a 
project coming up which would allow some work on this.


Sorry for all the questions, this work is very interesting to me.  Are 
you planning on continuing it at all?  I'd like to perhaps try to get 
some of it in GeoServer, as I think it could be valuable there.  But 
would likely be most valuable if it could be disk cached and get that 
piece _really_ fast, since it could be more efficient than storing full 
tiles.


Chris

Christophe Rousson wrote:



2007/9/11, Chris Holmes <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>>:


Do you have some benchmarks online anywhere?


To give you an idea, I set up a regression test with a dataset of 5000 
random features in the unitsquare, put these in a MemoryDataStore and 
ran 150 queries (queries are such that one query is in the neighbourhood 
of the previous one). Query window size is between 1/20 and 1/100 of the 
unitsquare.
In the worst case (the cache needs to query the source datastore and 
load new data in its storage), the overhead is on average +300 ms/query 
compared to MemoryDataStore.
The mean query execution time difference is about 40 ms in favor of the 
cache, as it uses indexation.


There are however some limitations :
. I only implemented a grid index, which is likely to be suboptimal in 
many cases. Quadtree or rtree index would do better, but there is not 
much work to do to adapt the cache on these.
. the cache stores features on a per feature type basis. It actually 
extends FeatureSource rather than DataStore, but it would be easy to 
wrap a number of cache instances around a DataStore to create a cached 
DataStore.
. current implementation is read-only, though it should be easy to make 
it write-thru.


Also, do you have a sense of how easy this might be to include in
GeoServer?  We use the datastore api directly, with the SPI mechanism to
make things plug-ins.  But I imagine yours would be a bit different
since it probably depends on another datastore that it's caching?  Or
maybe I'm totally misunderstanding your work.  It sounds like the ideal
would be to have a button in our UI that lets you wrap any of the
normally configured datastores with a caching one.



I think a sample code will do for a demonstration :

int feature_type_index = 0;
int number_of_nodes = 500;
int cache_feature_capacity = 1000;
DataStore ds = ... ; // get any instance of a datastore
FeatureCache cache = new GridFeatureCache(

ds.getFeatureSource(ds.getTypeNames()[feature_type_index]),

number_of_nodes,
cache_feature_capacity,
BufferedDiskStorage.createInstance());
// cache may be used anywhere you would normally use FeatureSource

I hope this somehow answers your questions.

cheers,

Christophe
!DSPAM:4005,46e72e8c94181431913854!




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/

!DSPAM:4005,46e72e8c94181431913854!




___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


!DSPAM:4005,46e72e8c94181431913854!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-

Re: [Geotools-devel] gpx module progress

[Chris Holmes]

Hmmm...  I'd be more inclined to just make the time a new attribute. 
You can hardcode the attribute name, like we do in shapefiles with 
'the_geom', call it 'timestamp' or something.  If time is just an 
attribute then we can use it straight away with GeoServer's KML Time 
support - we have a template thing that lets you just enter the name of 
the attribute to use.  Raster data often does the time thing with 4 
dimensions, but I feel like if you're working with vector data, as GPX 
is, then you should just throw an extra attribute on.  Elevation should 
likely be handled the same way, perhaps in addition to doing it as a 
third coordinate.  But an attribute can make it clear that it's in fact 
elevation, and not another type of 3d thing, like distance above the 
ground or something.


best regards,

Chris

Bolla Péter wrote:

Hi,

I've comitted a new version of the gpx data store, that now uses 
Justin's xml parser (so xstream and xpp dependency dropped). It's still 
r/o, but write support is the next step.


I tried to add it to uDig, but failed to do so, so tested only with a 
simple test case (loading a file, and printing the loaded feature).


If you feel like testing, give it a try!

I also had a discussion with Jody on how to implement the temporal data. 
(in the gpx file every point of a track, so the nodes of a line segment, 
has lon, lat, elevation and time data). This could be used when 
visualizing the features. The easiest way might be to extend the JTS 
Coordinate class, to support a 4. dimension, which can be the Date, and 
create the geometries using these extended coordinates.


Has any of you worked with temporal data like this, or with any 4D data? 
Or just any idea on how this could be best implemented?


Best,
Peter

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,46d78f8168541849620573!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] AbstractJDBCDataStore and its pilot implementation for Oracle Spatial

[Chris Holmes]

Do you have performance benchmark numbers vs. the old datastore?  It 
sounds like really great work, but I'd like to be sure that there's a 
clear win to switching to the new one, since I'm sure there will be some 
pain if it becomes the new default (lots of minor bugs will likely need 
to be fixed).  If it's much faster I think we could consider making it 
an optional download for GeoServer, which would likely get some more 
users testing it.

best regards,

Chris

Vitali Diatchkov wrote:
>
> As it was mentioned earlier, reader/writer approach is not very useful in
> case of features being processed through JDBC. 
> I had a goal to implement datastore for Oracle Spatial based on GeoTools
> architecture and interfaces to be used for direct access to Oracle database
> from UDIG. GeoTools' standard implementation is very narrow and not
> appropriate for high customization - I mean customization for data model
> being used in particular project.
>
> What is done is not a new Hibernate to bind Feature instances to table rows
> in the database. But the idea of "feature binding" is used. 
>
> There are several major parts in the "new" JDBC datastore framework design.
>
> The part where "feature binding" takes place is in package
> org.geotools.data.jdbc.operation. For SELECT/DELETE/INSERT/UPDATE SQL tokens
> there are interfaces like SelectJDBCOperation... etc. And there is a
> JDBCOperationFactory that creates instances of operations.  Implementors of
> operation interfaces encapsulate all SQL stuff to process Feature objects
> and bind them to the relational representation in  the database. 
>
> Feature objects and coming in and out to/from operations and this part of
> the framework is responsible for the SQL and real JDBC processing.
>
> Another part of the framework is AbstractJDBCDataStore class and other
> classes around it. AbstractJDBCDataStore mostly contains get/set methods to
> configure various factories, builders and providers:
>
> -JDBCOperationFactory
> -JDBCFeatureTypeBuilder
> -FIDMapperFactory
> -FilterToSQLFactory
> -ConnectionProvider
> 
>
> So, AbstractJDBCDataStore is general enough to let the developer charge its
> implementation for the particular database with different factories and
> builders that customize the framework for this particular database.
>
> SQL stuff is far from FeatureStore/FeatureSource/DataStore implementations
> and it is located in "operations" part of the framework.
>
> org.geotools.data.jdbc.prepared  - is a general implementation of JDBC
> operations that deal with prepared statements of JDBC.
>
> org.geotools.data.jdbc.type - is a package with classes to handle data types
> conversion (AttributeType of the feature <-> JDBC type ).
>
> JDBCConnectionProvider extracts physical Connection with respect to the
> passed transaction object. It does not replace the work what I see in H2
> module of GeoTools 2.5. The work has been done in H2 module related to
> getting physical connections from pools should be integrated in this
> framework to improve it. But JDBCConnectionProvider is a thing that works
> with already created and cached Connections with respect to transaction.
>
>
> For the convenience I merged UDIG UI and Geotools Oracle plugin with all
> made changes into one UDIG plugin for testing. To run this stuff it is
> necessary manually put Oracle's JDBC driver (ojdbc14.jar) into the lib
> folder.
>
>
> Come classes are almost full copies from GeoTools trunk but with some
> necessary changes for the framework. The idea is to force this stuff to
> work, then make backward improvements in GeoTools trunk if necessary if this
> framework would be useful for next JDBC architecture generation.
>
>
> Originally this framework and Oracle implementation was developed for UDIG
> 1.1 + GeoTools 2.2.x, but what is available in SVN - is a port for GeoTools
> trunk with latest changes in interfaces (like FilterToSQL instead of
> SQLEncoder). That's why some things were ported in a dirty way - just force
> them to work. And some work is required to bring things to date - I am able
> to continue this work for the community at my free time.
>
> What else.. may be something but later. Jody may be  is a person who could
> look into this stuff, comment or propose the next steps.
>
> I tested UDIG trunk + GeoTools trunk + Oracle Spatial 10g that is used in a
> production mode right now in projects for our customers. Of course, getting
> full functionality of INSERT/UPDATE queries requires some steps at the
> client side that is outside of GeoTools framework and more related to
> feature types model tuning to create valid Feature instances with acceptable
> values of attributes when there are various column restrictions at the data
> model in the database.
>
> Operations part of the framework is optimized for the performance not
> validation while our project was implemented in a such way that we guarantee
> that Feature instances coming into JDBCFeatureStore  are valid and conf

Re: [Geotools-devel] Hum... blog.geotools.org anyone?

[Chris Holmes]

It'd be pretty easy for us to set up a geotools blog on our same 
geoserver infrastructure, if there's interest and a volunteer to style 
it a wee bit.


Chris

Andrea Aime wrote:

Jody Garnett ha scritto:
Or news feed already acts as a blog; it is open for anyone to publish up 
articles etc


Hmm... I see. Did not think about it. Eventual blogs would be swamped
in between the irc logs thought. Look at GeoServer infrastructure,
things we want to tell users are not mixed in between strictly
developer related stuff.

I use it every couple of months or so. I would also 
like to see the SoC students use it. GeoTools does have a blog account; 
James added it back when we first lost all our IRC history.


A blog account where? What blog account?
Cheers
Andrea

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,46af583f197791637810514!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposed GPX i/o module

[Chris Holmes]

Which homepage?  It'd be good if the create your own module page had a 
link to the right instructions.


Jody Garnett wrote:
The home page has instructions for getting write access to the wiki 
(near the bottom of the page) - sorry for the trouble (we have had 
problems with spammers on codehaus).


Jody

Hi,

I've mentioned on the users list, that I would be happy to contribute 
my GPX file parser module to GeoTools.


Jody suggested to read this page:
http://docs.codehaus.org/display/GEOT/Creating+your+own+Module

Now I would be ready to write in the wiki about my concept, but I may 
not be privilegd to create a new page. If anybody could help me in 
that, would be fine. I signed up to confluence as 'buci'.


Thank you,
Peter




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,469f9e32313246491211187!

begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Lesser General Public License (LGPL)

[Chris Holmes]

Afaik we're at LGPL v2.  It's probably one that says version 2 or later,
which means anyone's allowed to do the upgrade to version 3.  But we
should decide as a project if we want to, get consensus from everyone
involved.

As far as I know v3 has no major downside and has a nice upside that helps
us - compatibility with apache license.  So I'm definitely for upgrading
to v3.

best regards,

Chris

On Tue, July 17, 2007 2:33 pm, Graham Davis wrote:
> I'm starting work on the IP review for the geometry module (not fun!)
> and noticed that the LICENSE.txt file seems to have the LGPL v2.1 text in
> it.  The POM file for my module however, links to:
> http://www.gnu.org/copyleft/lesser.txt  which is version 3.  Should the
> LICENSE.txt files be updated with this new text from the v3 file?
>
>
> --
> Graham Davis
> Refractions Research Inc.
> [EMAIL PROTECTED]
>
>
> -
>  This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
> !DSPAM:4005,469d0c9570262143011171!
>
>
>


-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] SoC report : data caching

[Chris Holmes]

I noticed you wrote 'FilterSplitter : a FilterVisitor that splits a 
filter into two filters, isolating spatial restrictions from other 
attribute restrictions.'


In GeoTools there is already a generic way to split filters: 
http://svn.geotools.org/geotools/trunk/gt/modules/library/main/src/main/java/org/geotools/filter/visitor/PostPreProcessFilterSplittingVisitor.java


You provide it with a FilterCapabilities, and I think for your case you 
could just make a capabilities that only has the spatial restrictions. 
If possible it'd be good to use that code, so we don't have code 
duplication with things that do very similar actions.


best regards,

Chris

Christophe Rousson wrote:

Hi list,

I updated project wiki page as work goes on.

You can have a look at :

http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data#SoC2007Cachingdata-notes 



http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data#SoC2007Cachingdata-TODO

Cheers,

 Christophe
!DSPAM:4005,46892092316662143011171!




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

!DSPAM:4005,46892092316662143011171!




___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


!DSPAM:4005,46892092316662143011171!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Connection pooling experiment on H2, and proposal ready

[Chris Holmes]

One other thought is to have the driver class name and url's filled out 
as defaults in the factory.  In an app like uDig they can just be part 
of the 'advanced' tab.  For GeoServer a user would get default values, 
and they wouldn't know what they do, so they'd just leave them in.  That 
might not be so bad, and could be better than making them pick one of 
two datastores.  And we could perhaps figure out some sort of 'advanced' 
tab when we get a new ui.


C

Andrea Aime wrote:

Hi,
I've updated the connection pooling 
http://docs.codehaus.org/display/GEOTOOLS/Connection+pool+subsystem+upgrade


Here are some notes on the implementation of the secondary SPI.
As usual, actually triying to implement the stuff showed up
some controversial points.

Let's say I'm setting up a generic DBCP DataSource. This means
I have to provide (some of) the parameter listed here:
http://jakarta.apache.org/commons/dbcp/configuration.html

Two of the primary parameters are url and driverClassName.
For postgres, for example, it would mean the user has to put in
values such as:
driverClassName=org.postgresql.Driver
url=jdbc:postgresql://localhost/dbname

This can be seen as a regression compared to the old system, since
when we did setup a postgis data store, the format of the url and
the driver class names where known, whilst setting up a generic
DBCP connection pool, they are not.
Yet being able to specify the URL is in some rare cases a must, for
example some months ago a user had lots of troubles setting up Geoserver
because he had to setup an SSL connection to Postgres, and our
"easy to use" configuration would not allow that (he would have
succeded if he could specify the url).

I know this sounds complicated, yet in my years working at SATA
I have used, in different occasions, every single config
parameter that DBCP provided me, and that happened every
time my apps were to be connected to a central db
administered by a full time DBA.
Those DBA have to ensure that no rougue application can ruin
the operation of the other apps and the central db, so they
do setup various kind of limitations on what an app can do,
such as, you cannot use more than 7 connections, a connection
cannot be idle for more than 1 minute, you cannot open
more than 20 prepared statements per connection, and so on.
To make the application work within those limitations, fine
tuning the connection pool is really a make or break.

I guess having two factories per datastore, one with the old
interface (datastore specific, asks for host, username, pw,
and eventually just the max connection number, and uses
dbcp internallY) and one that accepts a generic DataSource
setup with the DataSourceFactorySPI with the extra complication
of setting up a fully generic connection pool should
fit most requirements.

If you feel like voting the proposal, do so, otherwise, feedback 
appreciated.

Ah, implementation wise, since we have to switch all datastores
in one shot, shall we try and do the switch in a short lived
branch?

Cheers
Andrea



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,4673e79c259478362916074!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Shapefile I/O and character sets...

[Chris Holmes]

Yeah, the problem is definitely the DBF file, and the fact that they get 
written in lots of different charsets.  I have a patch that I need to 
apply, that was on 2.0.x of GeoTools but never made it over, that lets 
users specify an alternate dbf in the factory, when you're making the 
new shapefile datastore.  That's the best we've come up with to deal 
with the problem, afaik.


Chris

Sunburned Surveyor wrote:

We received an e-mail on the JPP Developer mailing list a few days
ago. The post basically involved a couple users in Eastern Europe that
were having problems reading and writing ESRI Shapefiles with
attribute values that used characters from Eastern European character
sets.

I know that GeoTools and Deegree both maintain ESRI Shapefile drivers,
and I thought I would ask how support for multiple character sets is
handled. Is this totally dependent on the underlying JVM and computer
operating system? Is there any code in place to warn the user or
present error messages when the driver encounters attribute values
with an unsupported character set?


From what I read in the DBF specification only ASCII characters are

supported in a DBF file. So is the problem really other programs like
OpenOffice that will write out DBF files with non-ASCII characters and
not with our ESRI Shapefile drivers?

Thanks for the help with this.

The Sunburned Surveyor

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:4005,46718f35218601012714783!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Removed "nojai" profile

[Chris Holmes]

It was on 2.3.x.  I'll try to give it a go on trunk, but I have no 
immediate need to build trunk, so it may be awhile.  But I'll report 
back when I do.


Thanks Martin.

Chris

Martin Desruisseaux wrote:

when I tried it on a fresh box I got past the usual "Range" error message, and
and was left with some failures based on ImageIO  dare I ask about a no
"imageio" profile?


-Pnojai was about "jai_core", "jai_codec" and "imageio".

Could you tell me in which module you got this error and was was the error
message please? As explained in my previous email, I tried to put JAI
dependencies only in the modules that need them. It worked for me, but maybe
some module have a different behavior on other machines, so please let me know.

Martin


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Removed "nojai" profile

[Chris Holmes]

Jody Garnett wrote:

Chris Holmes wrote:
Ok, maybe I'm interpreting something wrong, but I believe I now should 
be able to go to GeoTools 2.3.x and run 'mvn install' with maven 2.0.4 
with no -Pnojai and no JAI installed and it should work?  Or was this 
change just made on trunk?
I think this is only on trunk? And you need maven 2.0.5 ... and when I 
tried it on a fresh box I got past the usual "Range" error message, and 
was left with some failures based on ImageIO  dare I ask about a no 
"imageio" profile?

I'm pretty sure the original nojai profile also managed without ImageIO.

Chris



Cheers,
Jody

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Removed "nojai" profile

[Chris Holmes]

Ok, maybe I'm interpreting something wrong, but I believe I now should 
be able to go to GeoTools 2.3.x and run 'mvn install' with maven 2.0.4 
with no -Pnojai and no JAI installed and it should work?  Or was this 
change just made on trunk?


Because I just checked out gt and ran mvn install on 2.3.x and it failed 
with jai stuff.  If this could work then that would be great.


thanks,

Chris

Martin Desruisseaux wrote:

Hello Adrian

Adrian Custer a écrit :

You are playing fast and loose with the build system again. I hope
nothing breaks with these changes but am skeptical about the never
ending saga of the nojai profile. 


"nojai" do not exists anymore. I made the "nojai" profile permanent. This topic
was raised on the mailing list last week. If I remember right, we also raised
the topic in a IRC meeting a few weeks ago (but I'm not completly sure).



Why are you targeting maven 2.0.6? I thought gt had settled on 2.0.5.
Are these changes needed only for 2.0.6 or needed more generally?


The "nojai" profile was mandatory for Maven 2.0.6, and optional for Maven 2.0.5
and 2.0.4 (providing that the user installed JAI in his jre/lib/ext directory).
Maven 2.0.6 is stricter about classpath than Maven 2.0.5 was; it ignores totally
the content of jre/lib/ext. So the standard build (without "nojai" profile) is
useless with Maven 2.0.6.

The "nojai" profile was added in order to avoid the "symbol not found:
javax.media.jai.whatever" compiler error that numerous users meet. Prior to the
change I just made, the user had to specify the "-Pnojai" flag explicitly. Now
they don't need to specify this flag anymore.

Again, this is in reaction to the fact that "mvn install" without the "-Pnojai"
flag do not work anymore starting with Maven 2.0.6. So I though that it is
better to make the "nojai" profile permanent.



Is this the end of the road for the nojai profile? If so, what's the end
result for users: can they simply skip installing in the vm now?


User don't need to install JAI for building and testing with Maven. However they
still need to install JAI for running their own application with Geotools. This
is because JAI is declared with "provided" scope in Maven, meaning that it is
expected to already exists on the target desktop.

"provided" was the scope declared by the "nojai" profile and I didn't changed
that for "jai_core". I downgraded "jai_codec" from "provided" to "test" scope
when it was suffisient for Maven build. It make no difference for deployed
applications.

Martin

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-1264) FIDFactory wrongly skips if second column is auto-increment

[Chris Holmes (JIRA)]

FIDFactory wrongly skips if second column is auto-increment
---

 Key: GEOT-1264
 URL: http://jira.codehaus.org/browse/GEOT-1264
 Project: GeoTools
  Issue Type: Bug
  Components: data versioning postgis 
Affects Versions: 2.4.M2
Reporter: Chris Holmes
Assignee: Andrea Aime
 Fix For: 2.4.M3


Different versions of PostGIS return different orders for primary key columns.  
But the current code only check if the first column is an auto-increment one.  
If it's the second it is wrongly skipped.

Patch is:

Index: 
src/main/java/org/geotools/data/postgis/fidmapper/VersionedFIDMapperFactory.java
===
--- 
src/main/java/org/geotools/data/postgis/fidmapper/VersionedFIDMapperFactory.java
(revision 25399)
+++ 
src/main/java/org/geotools/data/postgis/fidmapper/VersionedFIDMapperFactory.java
(working copy)
@@ -98,7 +98,7 @@

 protected FIDMapper buildSingleColumnVersionedFidMapper(String schema, 
String tableName,
 Connection connection, ColumnInfo[] colInfos) {
-if (colInfos[0].isAutoIncrement() && colInfos.length == 2) {
+if (colInfos.length == 2 && (colInfos[0].isAutoIncrement() || 
colInfos[1].isAutoIncrement())){
 return new VersionedAutoincrementFIDMapper(schema, tableName, 
colInfos[0].colName,
 colInfos[0].dataType, colInfos[0].decimalDigits);
 } else if (isIntegralType(colInfos[0].dataType)) {


This is confirmed to fix the problem (using database on sigma.openplans.org, 
where the problem first arose).  Would like review, as I'm not 100% sure about 
evaluation order, and if left is not checked first then this will make an error 
on occasion.  I suppose I also could have just nested the evaluation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [JPP-Devel] Requesting some thoughts on GeoTools...

[Chris Holmes]

ibraries to build on.  GeoTools seems the clear and
obvious choice for this role.  Now what can we do to help it live up to that
role?

While I think there would be some benefits to actually changing out the
OpenJUMP feature model for the one in GeoTools, I can understand why that
would be a high risk step.  In the meantime I'd like to strongly encourage
you build some sort of adapter so that any geotools feature source can be
used as an OpenJUMP feature source, even if there is a bit of extra
conversion between feature models always going on.  And then stop work on
any data access code of your own, and throw in with GeoTools for this
functionality!  Get involved, help out, etc.  Just using parts of the low
level shapefile code on the other hand is essentially next to no cooperation
at all.

I don't know what OpenJUMP uses for coordinate system transformations, but
I will stress that GeoTools is quite sophisticated in this realm and this
would be another obvious aspect to take advantage of.

You mentioned the difference in GUI toolkits between OpenJUMP and
GeoTools (uDig?).  I don't think you should focus on sharing GUI
components at this time.  This is another whole ball of wax, and I'd
claim that the C/C++ world has shown that a huge amount of sharing
and leverage can be accomplished without sharing GUI components.

Anyways, this email is really my plea to OpenJUMP and indirectly to other
projects in the FOSS4G community to treat GeoTools as a building block,
to get involved and to provide strong feedback on the importance for
stability if that is important to you.

The Java world has a quite reasonable desire for "pure java" solutions,
but make that work I think it is important to share labour on a lot of
common low level components.

Best regards,
  



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Complex features from TOPP and the FGDC

[Chris Holmes]

So we got some great news today, our application for an FGDC CAP grant 
was accepted.  This will enable us to work on the complex feature model 
for GeoTools, as well as a WFS 1.1 datastore.  And then integrating all 
this in to uDig, and helping out to make it even more user friendly.


Details of the award are at: 
http://www.fgdc.gov/grants/2007CAP/Category2/07HQAG-NY


Our plan is to get all the complex feature work firmly on trunk.  There 
are a few contingency plans if we can't quite do it all the way, but we 
are scheduling a good bit of time to make it happen, so should at least 
make some solid progress.  We can likely delay starting a bit if others 
have potential for getting funded, as we very much want to collaborate 
on this.  If not we'll give it our best shot.


Chris

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PMC: parser package naming proposal going through by default

[Chris Holmes]

It probably makes more sense for me to step down than to just throw a +1
on this.  I haven't built GeoTools in way too long, and don't think I can
comment intelligently on most of what's going on.  I'm happy to give
advice on the areas that I do know, but I'm not active enough to make
these kinds of decisions.

Chris

>>>
>>> On Fri, 2007-03-30 at 09:46 -0700, Jody Garnett wrote:
>>>
>>>
>>>> So this second proposal did not get enough votes to be approved ...
>>>>
>>>>
>>>> The following people are casting a +0 vote by default:
>>>> - [~cholmes] +0
>>>> - Ian Turton +0
>>>> - Martin Desruisseaux +0
>>>> - [~rgould] +0
>>>> - [~simboss] +0
>>>>
>>>>
>>>> Sigh.
>>>>
>>>>
>>>> If we cannot interest the PMC in the proposal process we need to
>>>> try something else, return to the status quo, or change the guard on
>>>> the PMC
>>>>
>>>> Aside - after all of the discussion I finally found some example of
>>>> this kind of thing shipped with Java 5: -
>>>> http://java.sun.com/j2se/1.5.0/docs/api/org/omg/CORBA/package-summa
>>>> ry.html -
>>>> http://java.sun.com/j2se/1.5.0/docs/api/org/omg/CORBA_2_3/package-su
>>>> mmary.html -
>>>> http://java.sun.com/j2se/1.5.0/docs/api/org/omg/CORBA_2_3/portable/p
>>>> ackage-summary.html
>>>>
>>>> Cheers,
>>>> Jody
>>>>
>>>>
>>>>
>>>> ---
>>>> --
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>>> share your opinions on IT & business topics through brief
>>>> surveys-and earn cash
>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=
>>>> DEVDEV
>>>> ___
>>>> Geotools-devel mailing list
>>>> Geotools-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>>
>>>
>>
>>
>> ---
>> --
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your opinions on IT & business topics through brief surveys-and earn
>> cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD
>> EV
>> _______
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> -
>  Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>  ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PMC: CQL Supported status (and Mauricio to module maintainer)

[Chris Holmes]

+1

Jody Garnett wrote:

You votes are needed from monday's meeting

So the following proposal is going ahead:
- 
http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion 



It is just about package renaming at this time, CQL will remain a 
separate module - and move to supported status (provided the PMC votes 
now).


Cheers,
Jody

Here is the section from todays meeting:
 

so for now lets keep CQL out of the mix
I can always depend on it for my examples; ...
Just to be clear
I _love_ CQL
so should it move to supported status
and Mauricio become a module maintainer (as was 
requested in december?)

absolutely, it should move to supported status
okay then let me make that motion:
I move that CQL module move to library/cql and 
Mauricio be dragging along with it as module maintainer
he has shown a good understanding of eveyrthing 
geotools; has read the developers guide

and play's nice with others
+1 for me
+1
cholmes ping!
simboss ping!
rgould ping
+1 :-)
(distracted byt gsoc :-) )
|<--cholmes has left freenode (Read error: 110 (Connection 
timed out))

darn that is an anti ping for cholmes
It's a time out




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to 
share your

opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  




--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Activating the "nojai" profile by default: vote!

[Chris Holmes]

+1.  I've tried it, it works great, would be very nice to have it active 
by default.


Chris

Andrea Aime wrote:

Hi,
since I did not get much feedback about this, beyond a few
users that could build geotools only with the nojai profile,
I'm calling a vote.

I want to activate the nojai profile by default, but leaving it
as a profile, so that people can still disable it on demand.

+1 from me.

Cheers
Andrea

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PostPreProcessFilterSplittingVisitor vs. SQLUnpacker

[Chris Holmes]

Jody Garnett wrote:

Chris Holmes wrote:
I would find it much more clear to make a class that does this in one 
pass; that is accepts a filter and outputs both an SQL statement and 
the leftover filter that could not be encoded. That way we do not 
split up decision making between two classes.
No, the reason we don't do that is because the encodings can be 
different, indeed SQL is a misnomer.
Not sure I followed you ... I am talking about the SQLEncoder taking on 
the job of splitting as well.
I'm saying that we also have a WFS encoder, and WFS is not SQL, so the 
name SQLUnpacker is a misnomer, since it just generically splits things, 
to be used in sql or not.



  There are classes that 'do this in one pass', that make use of 
SQLEncoder.  But we don't combine splitting and encoding since 
different classes do their encoding differently.  I suppose you could 
theoretically have the splitting in a super class that all inherit 
from, but in my opinion it makes far more sense to have one class do 
it and reuse that class.
Different classes still do their encoding differently, they are also 
taking responsibility for building up the filter of things they could 
not encode.


Both solutions make sense; I just have a hard time debugging what went 
wrong with the current split then encode approach.
Interesting, I've never had a hard time debugging it because splitting 
is so simple and debugged that it always works.  Except for when they 
switched to the 'new' one and it didn't work.


Chris




Cheers,
Jody

!DSPAM:1003,45f09aa7188531194215290!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PostPreProcessFilterSplittingVisitor vs. SQLUnpacker

[Chris Holmes]

Asking around there was tones of stuff that SQLUnpacker did not do ... 
talking to Jesse we cannot remember the details right now.
Jesse has been fixing the PostPreProcessing but could not do all the 
simplification until he moves to trunk.
Yeah, 'tons of stuff', but when I asked for details all I got was the 
theoretical filter thing which wasn't implemented.  I backed down 
because they had already done the work, but in general I think we should 
start to get less accepting of new work unless it actually does 
something significantly better, and that justification should be 
provided.  Hopefully the new policies will make this happen more.  But I 
do regret not being more forceful about making use of SQLUnpacker, since 
it was one of the first pieces of code I wrote for GeoTools I thought 
maybe it was lacking.  But to be honest refactoring something that is 
being used and keeping the interface around is much better than throwing 
it out and writing something new.  Indeed when the switch was made it 
introduced new problems.  GeoTools is going to languish just being used 
by uDig and GeoServer until we figure out how to stick with an API, even 
if there are improvements that can be made.


Chris



Looking at *both* these implementations I think they are an example of 
code reuse getting in the way of clarity. It would be nice to have a 
utility class that breaks down a Filter into just the part you can 
encode, and then directly encode the good part into SQL with confidence.


I would find it much more clear to make a class that does this in one 
pass; that is accepts a filter and outputs both an SQL statement and the 
leftover filter that could not be encoded. That way we do not split up 
decision making between two classes.


Cheers,
Jody



Farber, Saul (ENV) wrote:

This is kind of a targeted question, but I'll throw it out to the list to see 
if anyone else can answer too.

Why is SQLUnpacker deprecated?

Looking at PostPreProcessFilterSplittingVisitor the only thing I can figure 
that it's doing that SQLUnpacker isn't doing is handling client-side 
transactions via a ClientTransactionAccessor.

Is there something fundamentally flawed about SQLUnpacker?  I do have to say 
that SQLUnpacker is MUCH more clearly and concisely written.

--saul

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45f09751185341362196140!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PostPreProcessFilterSplittingVisitor vs. SQLUnpacker

[Chris Holmes]

Jody Garnett wrote:
Not sure off the of my head - what does the @deprecated annotation tell 
you to use? Oh I see PostPreProcessFilterSplittingVisitor.
Looks like a case of duplication of code; and the community going with 
the one that had more tests and was maintained.


Asking around there was tones of stuff that SQLUnpacker did not do ... 
talking to Jesse we cannot remember the details right now.
Jesse has been fixing the PostPreProcessing but could not do all the 
simplification until he moves to trunk.


Looking at *both* these implementations I think they are an example of 
code reuse getting in the way of clarity. It would be nice to have a 
utility class that breaks down a Filter into just the part you can 
encode, and then directly encode the good part into SQL with confidence.


I would find it much more clear to make a class that does this in one 
pass; that is accepts a filter and outputs both an SQL statement and the 
leftover filter that could not be encoded. That way we do not split up 
decision making between two classes.
No, the reason we don't do that is because the encodings can be 
different, indeed SQL is a misnomer.  There are classes that 'do this in 
one pass', that make use of SQLEncoder.  But we don't combine splitting 
and encoding since different classes do their encoding differently.  I 
suppose you could theoretically have the splitting in a super class that 
all inherit from, but in my opinion it makes far more sense to have one 
class do it and reuse that class.


C




Cheers,
Jody



Farber, Saul (ENV) wrote:

This is kind of a targeted question, but I'll throw it out to the list to see 
if anyone else can answer too.

Why is SQLUnpacker deprecated?

Looking at PostPreProcessFilterSplittingVisitor the only thing I can figure 
that it's doing that SQLUnpacker isn't doing is handling client-side 
transactions via a ClientTransactionAccessor.

Is there something fundamentally flawed about SQLUnpacker?  I do have to say 
that SQLUnpacker is MUCH more clearly and concisely written.

--saul

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45f09751185341362196140!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] PostPreProcessFilterSplittingVisitor vs. SQLUnpacker

[Chris Holmes]

Well thank you!  (I wrote it, and was told that it was no longer good 
enough)


The justification I got was that the superlongnamedvisitor had more 
potential for extensibility, that in theory it'd be able to handle 
filters better.  Which I concede, as sqlencoder isn't designed for 
filters, but as of yet there's not much filter stuff in the visitor thing.


I was fine to have it deprecated since it doesn't make sense to have two 
things that do basically the exact same thing.  I never got a clear 
explanation as to why it was written in the first place, I know it was 
for the WFSDatastore.  But it's used in PostGIS now, which is when I got 
the above explanation.


Chris

Farber, Saul (ENV) wrote:

This is kind of a targeted question, but I'll throw it out to the list to see 
if anyone else can answer too.

Why is SQLUnpacker deprecated?

Looking at PostPreProcessFilterSplittingVisitor the only thing I can figure 
that it's doing that SQLUnpacker isn't doing is handling client-side 
transactions via a ClientTransactionAccessor.

Is there something fundamentally flawed about SQLUnpacker?  I do have to say 
that SQLUnpacker is MUCH more clearly and concisely written.

--saul

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45f090bb178271995013331!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] An example of code sprint - crash the party

[Chris Holmes]

If possible I'd really push for at least three to four days for 
sprinting.  The non-geo half of TOPP has lots of sprinting experience, 
indeed they're off to a sprint next week.  They say one day can be 
successful, but you need to have a really good idea of what you're doing 
beforehand, and to be pretty experienced with sprints.  They've done up 
to 8 days, so 3-4 sounds like a good amount to get started with.


I think it could make good sense to have geotools/geoserver/udig all 
sprinting in the same place.  Have a few different goals, with different 
groups of people focused on them, but easily be able to grab people from 
other groups.


I'm planning on having all of TOPP out at the conference, and can 
definitely have us all come early or stick around after to work away. 
If there's a good space out there we could all get that would be great.


Chris

Jody Garnett wrote:

Andrea Antonello wrote:

What do you mean by "crash the party" (sometimes miss some pieces of
language)? Mix up the two things?
  
A "party crasher" is someone who goes to a party with out an invitation 
(just to eat the free food). There was a recent movie
called wedding crashers (a comedy that involved crashing wedding 
receptions for free bridesmaids plus food).


However uDig is *invited* to this party. If we can round up enough 
people then we can set aside a room and internet
for a uDig hackfest.  (Indeed GeoServer has not expressed any interest 
at this time).


One idea I had was to take on a tough problem: such as updating the 
feature model in geotools - and running the change through uDig and 
GeoServer it

would be a long day (but save us all lots of grief).

I'm setting up a WIKI page for ideas for the code sprint.
  

Great! I will soon contribute some stuff

If code sprint day is Friday, perhaps that can be our warm up and we can
do our real uDig hack session monday/tuesday (i'm sure several of the
uDiggers will want to attend the Geotools sprint too).  Are many
planning on hanging around the following week?


If there is this code sprint opportunity for udiggers I give my +1 for
the following week.

Andrea

___
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
  



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45ef0256244711665516417!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Fixing dates GML encoding (and treatment in feature types, too)

[Chris Holmes]

I'd be happy to use those classes for time.  I wasn't really seriously 
we come up with our own time classes - more trying to get at what 
Justin's approach would do when existing java classes don't offer the 
level of granularity that XML might need.


Chris

Bryce L Nordgren wrote:


[EMAIL PROTECTED] wrote on 03/06/2007 04:14:18
PM:


In my mind this isn't so much about building it to a particular exchange
format - it's just making our model more granular.  There are a number
of different java objects for dates and times, but we squash them all in
to one Temporal Attribute Type.  This is just letting that attribute
Type have knowledge of a few more types.
Would the solution be to make new Java classes that better deal with the
granular information?  I think that could work with this if need be...
we could extend Date to be particular kinds of dates.


Chris, before you begin work on this, please checkout and evaluate the
19108 implementation referenced on
http://jira.codehaus.org/browse/GEOT-1186.  I believe the interfaces are
already in GeoAPI pending.  Actually, if you find it valuable, could you
consider that code to be a "patch" submitted to GeoTools by Alex in order
to begin the process of granting him commit access?

Please don't make up Java time classes.  We already have them, at least we
have interfaces...We're supposed to use them for time (ala ISO 19109), and
it sounds like there's no time like the present. (groan) Java time classes
are not the reference.  19108 interfaces are. :)

If you like, but want more documentation, 19108 is one of the "cheap" ISO
standards for Americans.  Go online with your credit card and $30 (US)
later, you download a "watermarked" PDF to your desktop.
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO+19108%3A2002

If I recall correctly, "TemporalAttributeType" should become any child of
"org.opengis.temporal.TemporalGeometricPrimitive".

Bryce


!DSPAM:1003,45edfedd113847785049143!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Fixing dates GML encoding (and treatment in feature types, too)

[Chris Holmes]

In my mind this isn't so much about building it to a particular exchange 
format - it's just making our model more granular.  There are a number 
of different java objects for dates and times, but we squash them all in 
to one Temporal Attribute Type.  This is just letting that attribute 
Type have knowledge of a few more types.


I don't think this leaves wfs 1.1 and gml3 encoding out in the cold, or 
at least I hope it doesn't - what happens if the xml schema data types 
are more granular than existing java classes?  Are we limited there to 
only doing XML output types of things that have Java classes?


Would the solution be to make new Java classes that better deal with the 
granular information?  I think that could work with this if need be... 
we could extend Date to be particular kinds of dates.


Chris

Justin Deoliveira wrote:

Hi Andrea,

This approach will leave wfs 1.1 and gml3 encoding out in the cold since
it takes a different approach to this. It relies on coming up with
defined mappings from java classes to xml schema data types. I admit
that in the case of dates the mapping is not clean.

Also, building things specific to a particular exchange format or
presentation directly into the data store doesn't seem quite right. I
mean what do we do if we want to encode features in another format that
has different data types than that of xml. Do we have to update each
data store again to provide the information in order to map correctly
for that format too?

Its a tough one. On the one hand I want to see the mappings from java to
xml separated into a single place. On the other hand the java classes do
not give us the granularity we need.

-Justin


Andrea Aime wrote:

Hi,
tomorrow I'd like to go and fix GEOT-620, so that our GML encoded
date do respect the data store settings.

Basically, I want to extend TemporalAttributeType to have an enumeration
(list of ints, codelist?) that allow us to say which kind of Date is 
that, xs:date, xs:datetime, xs:time, and have feature types and features

encoded accordingly.

It would be up to the datastore to provide the right information into
the feature type, if missing, we default to datetime.
I'm going to fix postgis, other datastores may follow at their 
leisure... at the moment we're broken in any case, our GML output

never really validates since we don't respect the xml schema
restrictions on the xs:date* types.

Cheers
Andrea

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel








--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Fixing dates GML encoding (and treatment in feature types, too)

[Chris Holmes]

Rob Atkinson wrote:

Andrea Aime wrote:

Hi,
tomorrow I'd like to go and fix GEOT-620, so that our GML encoded
date do respect the data store settings.

Basically, I want to extend TemporalAttributeType to have an enumeration
(list of ints, codelist?) that allow us to say which kind of Date is 
that, xs:date, xs:datetime, xs:time, and have feature types and features

encoded accordingly.

It would be up to the datastore to provide the right information into
the feature type, if missing, we default to datetime.
  
is there a consensus on how to do this?   currently we are hoping the 
persistence schema maps directly onto an XML schema type, which is naive 
and dangerous.


Generally, we want a separation between the Featuretype (actual model) 
and the datastore (persistence schema) and the GML (encoding).  The key 
thing is to allow a FeatureType to have some control over bindings from 
the persistence layer into the object model, and into the GML encoding.  
Any time we hardcode an assumption they are one and the same, we are 
basically introducing a problem.


IMHO we need:

Explicit mappings from a FeatureType into the desired type
Sensible defaults
Ability to register plug-ins (Type handler libraries) that may add or 
override defaults


Right, which is the whole purpose of the Feature Model work, no?  This 
work now is simply a fix to slightly improve the ability of the 
persistence schema to accurately report what it consists of.  This will 
help when we have the ability to do mappings, since the persistence 
schema will have more detailed knowledge and better sensible defaults.


Chris



Rob A
I'm going to fix postgis, other datastores may follow at their 
leisure... at the moment we're broken in any case, our GML output

never really validates since we don't respect the xml schema
restrictions on the xs:date* types.

Cheers
Andrea

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geoserver-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45ededc6101721336712104!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] transitive dependency ok? gt2-validation->gt2-directory->gt2-gml

[Chris Holmes]

Also how did the directory datastore get in to our default GeoServer 
distribution?  I tried it out and it doesn't work at all, asks you for a 
list of extensions but then can't read the input at all, says it can't 
get a String from the text.


Justin Deoliveira wrote:

If I remember correctly the dependency from directory on gml ( and
shapefile ) are just used for testing. They should probably be changed
to be of scope "test". Not sure this will help us just developing in
eclipse though... but for release it should make it so that they are not
included.

Gabriel Roldán wrote:

Hi, sorry for cross posting, but this is a problem affecting geoserver.
I don't have much time as to get deeper on this right now, but just wanted to 
know if the transitive dependency on gml datastore carried out by 
gt2-validation->gt2-directory->gt2-gml is alright or something that should be 
just for test scope.


In any case it is forcing geoserver to include the gml datastore, and in turn, 
the gml datastore factory is catching up every set of datastore parameters 
that has a "url" key (I know it is circumstantial and the same could be 
caused by any other file datastore that expects no "dbtype" like parameter).


In any case, should we make a compendium of all available datastore parameters 
and look for incompatibilities? or force all datastores to have a dbtype 
parameter?



Gabriel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geoserver-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel








--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Plugins 5 star test; modified to include email vs users docs requirement

[Chris Holmes]

 >> In terms of specifics ...you know how GeoServer extends plugins a
degree of trust (that the quality is good enough that you can handle 
the support emails?). uDig has the same tradeoff but our user 
community is different.


I don't really think we have a formal procedrue. It's about user asking
for them I guess, if a plugin stays long enough in the extra ones and
does not cause much troubles, I think it gets promoted to the standard
distribution. Not sure thought, Chris?


Actually we've booted quite a few in to datastore extras.  Basically 
everything except shapefile and postgis.  Those are the only two we 
agree to official support.  If TOPP feels we can handle all support 
requests that no one else volunteers to do then we'll include it in the 
standard distribution.


Though Oracle and ArcSDE and DB2 will probably always stay as separate 
downloads, even if we deem them very good, because all require external 
jars that we can't provide.  So it's useful to have them as a separate 
download so people specifically follow the instructions there.


Chris




Cheers
Andrea

!DSPAM:1003,45e47fb3325751804284693!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Mailing list archives outdated?

[Chris Holmes]

I tend to just use nabble:

http://www.nabble.com/GeoTools%2C-the-java-GIS-toolkit-f4260.html

We probably should bug sourceforge about our archives not showing up 
there though.


C

Matthias Basler wrote:

Hi GeoTools community,

when I follow the mailing lists > geotools-devel > archives links from any of 
the two links:
  http://docs.codehaus.org/display/GEOTOOLS/Home
and
  http://geotools.codehaus.org/

I find that the mailing list archives show the state of May 2006.

Any explaination?
Where can I find the more recent mails archived?


--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ConnectionPools and JNDI

[Chris Holmes]

Note that there's been a bug fix for jndi connection pools to work with 
Oracle.  See: http://jira.codehaus.org/browse/GEOS-778


It has an attached zip that shows how they did it.

Jody Garnett wrote:

Thanks for the informative discussion .. as promised here is my tough plan:
- http://docs.codehaus.org/display/GEOTOOLS/J2EE+and+Connection+Pools

Currently I only have scope to fix this problem for EPSGDefaultFactory 
... I have outlined

the plan for JDBCDataStore as well.

Cheers,
Jody

Jody Garnett wrote:

Thanks Andrea! That was a great overview of the trade-offs.

I am looking at how we do connection pools in GeoTools - but more 
towards JNDI lookup then
handling of prepared statements. Is there anything you would like me to 
look out for when

I do this work?

It sounds from your email that a shared connection pool in a J2EE 
setting (ie shared with

other web applications) may result in a glut of cached prepared statements?

Jody
  


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45ddf70c49141775926497!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Q&A Status of ShapefileDataStore

[Chris Holmes]

Merge or just rename - either way the IndexedShapefileDataStore should 
be named ShapefileDataStore.  The index is an option in the factory to 
turn off or on.


+1 on this, I've been trying to push for it for a long time, since that 
was always the intent of the indexedshapefile.


C

Jody Garnett wrote:

Hi Andrea got some answers by virtue of taking Jesse to coffee.

Apparently the original ShapefileDataStore can be retired (constructors 
set to protected, factory unplugged etc...), although perhaps it would 
be nicer to merge the two implementations.


Jody

Andrea Aime wrote:
For the case of the single shapefile the datastore factories get to 
fight over handing the result, you would have to play with the hint 
system to prefer one over the other. I think the original shapefile 
ds can be retired now? (Jesse?)

Are the issues with writing and file locks on windows fixed?
Cheers
Andrea



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45dde08028236309890654!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Postgis and sql injection

[Chris Holmes]

Andrea Aime wrote:

Jody Garnett ha scritto:

Thanks Andrea! That was a great overview of the trade-offs.

I am looking at how we do connection pools in GeoTools - but more 
towards JNDI lookup then
handling of prepared statements. Is there anything you would like me to 
look out for when

I do this work?


Yeah. Not everybody is using JNDI, so please leave the door open for
manually configured pools where JNDI is not available.
I would really like to see some kind of pluggable API allowing the
usage of DBCP, C3PO and the like, JNDI being a player like the others.
And have a default pooling too, maybe based on DBCP.


+1.  The current state is that we've essentially rolled our own (less 
feature complete) version of DBCP.  I looked in to it a bit ago and it 
shouldn't be that hard to stick different connection pool plug-ins 
behind an interface, but I believe it'll require a slight change in what 
we pass from the factory to the datastore - we pass in our 
ConnectionPool object now, and it should be a more standard JDBC 
interface that all connection pool plug-ins can generate (think maybe 
DataSource?).


C



It sounds from your email that a shared connection pool in a J2EE 
setting (ie shared with

other web applications) may result in a glut of cached prepared statements?


Yeah, it would. It's usually best to configure one connection pool
for application. That's what I've seen in production environments
around here, each app is given a small but private connection pool, 
usually around 10 connections.

If you have a shared one, the most active app using prepared statement
will rule the pool (ps wise).

Cheers
Andrea

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45ddd67118251971556521!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filter and ISO Feature on trunk

[Chris Holmes]

Gabriel Roldán wrote:

On Tuesday 06 February 2007 19:21, Jody Garnett wrote:
You are working on trunk I assume? 

yup


I was hoping feature model work would be 2.5.  I guess that's just a 
dream, since 2.4 isn't even at release candidate and 2.3 is not at final?


C

The JPox stuff is there with test 
cases. I would like to move

those test cases into *main* testing with simple collections of POJOs.

as far as I can tell, jpox doesn't compiles.
Yet, moving the test cases to trunk means moving the PojoPropertyAccessor too, 
correct?
I also know I wrote a more complex test case sometime using the metadata 
stuff, can't seem to find it right now...



Gabriel I have gotten this to work against POJOs; I have met the bug you
are talking about before (and fixed it). I do hope it
has not returned ...

looks like :(

So ok to fix it or not? I could just attach a patch to the jira issue if you 
wish.


Gabriel


Jody


Hi all,

sorry I seem quite these days. Beleave me I'm not, was just a bit sick
and couldn't show up on yesterdays meeting.

So I'm working on porting ISO Feature to trunk in an unsupported module.
That's the easy part, integration the hard.

As to get started, I would need our Filter implementation to work over
ISO Feature. I know PropertyAccessor should do its work here, but it
gets never called whatsoever, since Filter.evaluate(Object) is hardcoded
to return false.

So I would need permission to make Filter actually working over Object
and hence making it work over ISO Feature being a matter of having the
corresponding PropertyAccessor.

Gabriel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [udig-devel] Testing for RC9 (plus image pyramid plans)

[Chris Holmes]

However, it seems like Simone can lead us to bigger and better things.
Simone, when uDig eventually integrates your work, will it be possible
to make a set of structured requests of the WMS to build a temporary
image pyramid to improve user responsiveness. A user has at most
2000x2000 pixels on their screen. The base request should be for
whatever area of interest (extent and scale) the map has when the user
adds the layer to the map (or makes it visible). However, once that
request is fulfilled, couldn't uDig start building an image pyramid on
the fly so that whatever the user does next (pan, zoom) uDig would have
the data. We can see immediately that there are a whole slew of issues
that arise in designing such a background pyramid building. Is this
something some of you have been pondering? 


In my opinion the best way to do this would be to follow the WMS Client 
recommendation: 
http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation


This is what openlayers uses, so we'd benefit from the caching of 
servers that openlayers is hitting.  They pre-request a buffer, but not 
the next zoom level.  uDig could also easily cache and pre-cache in this 
way.


Chris





Thanks again for all the work on RC9,
--adrian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45c4d0dc203092207481331!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] langague policy - vs J2EE

[Chris Holmes]

Which would be 2.4 or 2.5?  It'd be good to get the 2.4 release at least 
without need 1.5.


We also might consider calling it GeoTools 3.0 if we go 1.5.

Jody Garnett wrote:
I must confess the unsupported/geometry module is giving me some panic 
on this front. I like the work I see their and would not like to ask 
them to "roll back" to Java 1.4. Especially since they have met the 
letter of developers guide ...


Sigh,
Jody


Martin Desruisseaux wrote:

Le mardi 30 janvier 2007 à 13:32 -0800, Jody Garnett a écrit :
Java EE has been out since May and I wonder how GeoServer fairs in 
that environment. Is everything okay, or are we going to take the 
more realistic step and check back when J2EE has been adopted by 
more major vendors? I would like to know how things are shaping up; 
do we have work to do?

I guess that Geotools 2.4 would stay with Java 4. But me too I would
like to know if it is possible to consider a move to Java 5 for Geotools
2.5. I miss all the features about generic types.
I'm usually the one who's against this the most, and I'm coming closer 
to it.  I'd like to have it a bit higher than just J2EE releases.


From my perspective it's important that sys admins who run GeoServer 
are on 1.5+.  The other concern is running on more obscure open source 
OS's, like the BSD's.  They take awhile to get java implementations. 
This should get better with the open source thing, but it's not there 
yet.  So I think it's getting closer, but we should do some more 
research.


Chris


Martin



- 

Using Tomcat but need to do more? Need to support web services, 
security?
Get stuff done quickly with pre-integrated technology to make your 
job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache 
Geronimo

http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel






-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45c2470b171661460912952!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] langague policy - vs J2EE

[Chris Holmes]

Martin Desruisseaux wrote:

Le mardi 30 janvier 2007 à 13:32 -0800, Jody Garnett a écrit :
Java EE has been out since May and I wonder how GeoServer fairs in that 
environment. Is everything okay, or are we going to take the more 
realistic step and check back when J2EE has been adopted by more major 
vendors? I would like to know how things are shaping up; do we have work 
to do?


I guess that Geotools 2.4 would stay with Java 4. But me too I would
like to know if it is possible to consider a move to Java 5 for Geotools
2.5. I miss all the features about generic types.


I'm usually the one who's against this the most, and I'm coming closer 
to it.  I'd like to have it a bit higher than just J2EE releases.


From my perspective it's important that sys admins who run GeoServer 
are on 1.5+.  The other concern is running on more obscure open source 
OS's, like the BSD's.  They take awhile to get java implementations. 
This should get better with the open source thing, but it's not there 
yet.  So I think it's getting closer, but we should do some more research.


Chris



Martin



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45c1192b279581116498154!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Joining GeoTools...

[Chris Holmes]

Jody Garnett wrote:

Frank Warmerdam wrote:

Were you or Chris going to look into getting a confluence license so
we could do this?   Does someone from GeoTools have expertise setting
something like this up if we provide a place?

I have experience.

A lot of the real developer facing need has vanished (codehaus uptime 
and performance has improved), but matters facing our user community 
(such as the one above) are not in our face day to day.


It would be nice to get geoserver.osgeo.org working though.

And we have some percentage paid time for a sys admin on OSGeo boxes 
now, no?  That was the other hold up before, no real good place to put it.


Chris



Jody

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1003,45c10a71260111410093335!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Introduction as new developers

[Chris Holmes]

Paul Ramsey wrote:

Andrea Aime wrote:

We are a company working basically on environmental informatics and 
geodata processing, and we have two applications for which Geotools is a 
strong candidate to be used within. The first one, which I am involved 
in, is a desktop application to display satellite orbits and 
corresponding swaths of instruments onboard these satellites. 

Have you evaluated uDig in this respect?


Another possibility in the near future might be the Java Worldwind, 
which is just entering closed alpha testing. Could be that the delivery 
date is too far in the future though.


Do we have any idea of if Java Worldwind is using any GeoTools stuff? 
Or at least JTS, or other Java geo stuff?  I remember seeing one of the 
reasons that they were doing Java is that there was a bigger java geo 
world.  Obviously at some point someone would write some integration, 
but am wondering if it's on the table already.


C



P



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-users] Null pointer exception

[Chris Holmes]

Let's ping GeoTools, as I remember some discussions about such things there.

Do you have a longer stack trace at all?  And what was the last release 
candidate that was working for you?


thanks,

Chris

Stephen Crawford wrote:

All,

Well, it's happening again.  This message writes to the logs, over and over
every few milliseconds, and the log files quickly become many GIGS in size:

535035713 [WARNING] WeakCollection - NullPointerException
java.lang.NullPointerException
at
org.geotools.util.WeakCollectionCleaner.run(WeakCollectionCleaner.java:76)

I've narrowed it down to happening when I try to shutdown Tomcat to update
files/settings/etc.  The proccess never shuts down unless we kill it.  Once
killed, I remove the log files, start Tomcat, and it all works finebut
that's not the best way to restart Tomcat.

Running GS 1.4.0.  The problem seems to have started when I upgraded from
the last release candidate, though it's hard to pinpoint because I didn't
notice for a week or so.

Any ideas?

Thanks,
Steve

Stephen Crawford
Center for Environmental Informatics
GeoVISTA Center
The Pennsylvania State University
814.865.9905
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geoserver-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:1003,45b7c4b6215341804284693!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Letter of support for FGDC Grant.

[Chris Holmes]

We got a majority of the PSC +1ing it, so I passed along to the OSGeo 
board, so they could vote on it tomorrow.  I will put the finalized 
letter in the formal correspondence.


Chris

Jody Garnett wrote:

So after Monday's meeting this should be taken care of right?

Here is a page to link the pdf to:
- http://docs.codehaus.org/display/GEOTOOLS/Formal+Correspondence

Thanks again Chris,
Jody

Hey all, TOPP is applying for a grant from the US Federal government 
that would allow us to build a WFS 1.1 datastore and GML 3.1.1 parser 
capable of handling the FGDC 'framework' data layers.  This would also 
fund at least some work to help get the complex feature model on to 
trunk.


I've asked for a letter of support from OSGeo, and Frank said it'd be 
good if the letter came from the GeoTools PSC, with endorsement from 
the OSGeo board.  I've come up with some sample text, which it would 
be great if we could approve.  It's just seeking to make a bit 
explicit the general benefits of open source development, and to help 
them see that it will have a wider impact.  I just came up with the 
text, and can change things around if need be.  But I'd very much like 
some support from the GeoTools PSC, to at least say this would be a 
nice thing.  The parts in << >> are basic text that I may have OSGeo 
include, but from the GeoTools side it's just the other parts of the 
text.




Chris Holmes, Managing Director, Strategic Development
The Open Planning Project
349 W. 12th street, #3
New York, NY 10014


Dear Chris,

The GeoTools Project Steering Committee has met and we would like to 
express our wholehearted support for your proposal to build an open 
source client for FGDC Framework data through Web Feature Service and 
GML 3.1.1 built upon GeoTools.  We understand that a major portion of 
this work will be contributed back to the GeoTools project, as a 
generic Web Feature Service client capable of handling WFS 1.1 and at 
the very least the required FGDC Framework data layers.


 We believe that the WFS 1.1 datastore and GML 3.1.1 parser built by 
The Open Planning Project with funding from Cooperative Agreement 
Program will be widely used, not just in the uDig client targeted by 
the grant, but also by any other Java-based project.  Additionally it 
will allow an improvement in the core Feature Model to handle the 
Framework Application schemas, which has long been a goal of the 
GeoTools community - to be the best parser and toolkit for handling 
complex GML and putting it in to a useful object model.  We believe 
this work have an large impact past the immediate funding, as GeoTools 
is liberally licensed to allow for even commercial implementations to 
build upon the same library.


The GeoTools community pledges to continue to maintain the work 
completed for the grant, making it available to any potential users of 
the library for the indefinite future.  The GeoTools Project Steering 
Committee also agrees to assist The Open Planning Project in 
integration to the core library, offering code reviews and advice to 
make sure that it becomes a core part of the library.  TOPP has long 
been a core contributor to the GeoTools Project, and we anticipate a 
very healthy working relationship.


<and gives their full endorsement to this project.  When the project is 
completed OSGeo will promote the work done as part of the Cooperative 
Agreement Program to the members of the wider open source geospatial 
community.  The board is pleased to see this work taking place, and 
believes it has the potential to have a large impact not only in the 
open source world, but in the geospatial software world in general>>.


Sincerely,

The GeoTools Project Steering Committee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to 
share your

opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
  



!DSPAM:1003,45afce9750758365517736!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you

Re: [Geotools-devel] On code changes and QA

[Chris Holmes]

Yeah, that sounds ideal.  The abstract JDBC infrastructure is obviously 
hosed right now - the reality of working with it ends up making things 
more difficult due to the amount of hacks to get the subclasses working.


I agree that H2 would be a great time to have another go at JDBC helper 
methods or abstract methods that are actually useful and don't impose a 
burden.  I imagine that a couple abstract helper methods might still be 
useful, but that much of what we try to do is likely better off in some 
utility classes.  We've had a lot of good lessons, and we should try to 
learn from them, make it easier for others to write new jdbc datastores. 
 Should definitely talk to David Adler as well, he had some ideas on 
how to make it easier as well.  If we build a nice infrastructure it 
should be relatively easy for existing datastores to port over if they 
choose.


Chris



Justin Deoliveira wrote:

Hi Andrea,

Thanks for your thoughts. About PostGIS, originally rewriting it seemed
like a good idea. But for the exact same reasons you listed. Reproducing
the functionality while making the code cleaner is no simple task. Part
of making the code cleaner is getting rid of some of those hacks, which
then changes the datastore. For these reasons, I dont think its
realistic to take on this kind of effort.

However, what I would really like to see is a good abstract JDBC
datastore. One made with the intent to extended. Breaking out "template"
methods where needed, making it final if need be, etc...

It seems like there is a fair amount of interest in having an H2
datastore. I was thinking this might be a much more logical candidate to
do this type of thing with, since there are no pre-existing expectations
to live up to.

-Justin

Andrea Aime wrote:

Hi,
two things Jody said during yesterday IRC meeting made
me think tonight.

I don't have the logs for the pre-meeting, but the first
one was something like how deep is the level of optimizations,
workarounds and details in the postgis data store, and how
nice is the new experimental one.

The old one is ugly, no doubt. Making a new one with a cleaner
structure is a good move for long term mantainance. I agree
on this too.
Yet, the "level of optimizations, workarounds and details"
is what makes the postgis data store our best jdbc data store,
that is, something that most of the time just works fine,
with whatever load of data you throw at it, and with various
levels of badness handled transparently.

What I would like to make people appreciate is the amount
of work that went into the old ugly data store, days of fine
tuning, bug fixing that are not evident and not checked by
just the unit test suite. Making a new one that passes the
same tests as the old one is just a first step towards something
that can be used as a replacement.
Before venturing into such a change, one has to understand
intimately the old and ugly one, appreciate the why and the hows
things were done in a certain way.

As an alternative, that may work on widely used modules, check
out the list of closed bugs on the module and ask yourself whether
there is a test for them, and whether the new module exhibit
the bad behaviour described in there.
If we all added a junit test for each bug found, that would not
be necessary, but since history proves otherwise, it's an
exercise everyone doing big changes should try out.

This is not to say that we don't need change. We do.
But we need a change that provides improvements, not regressions.
A big changes that disregards detailed correctness and performance
issues is a sample of the "small blanket" problem,
you try to cover your shoulders, and end up with cold feet.

So every time you work on a big change, think about it also
from this point of view :-)

Cheers
Andrea

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel








--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief

[Geotools-devel] Letter of support for FGDC Grant.

[Chris Holmes]

Hey all, TOPP is applying for a grant from the US Federal government 
that would allow us to build a WFS 1.1 datastore and GML 3.1.1 parser 
capable of handling the FGDC 'framework' data layers.  This would also 
fund at least some work to help get the complex feature model on to trunk.


I've asked for a letter of support from OSGeo, and Frank said it'd be 
good if the letter came from the GeoTools PSC, with endorsement from the 
OSGeo board.  I've come up with some sample text, which it would be 
great if we could approve.  It's just seeking to make a bit explicit the 
general benefits of open source development, and to help them see that 
it will have a wider impact.  I just came up with the text, and can 
change things around if need be.  But I'd very much like some support 
from the GeoTools PSC, to at least say this would be a nice thing.  The 
parts in << >> are basic text that I may have OSGeo include, but from 
the GeoTools side it's just the other parts of the text.




Chris Holmes, Managing Director, Strategic Development
The Open Planning Project
349 W. 12th street, #3
New York, NY 10014


Dear Chris,

The GeoTools Project Steering Committee has met and we would like to 
express our wholehearted support for your proposal to build an open 
source client for FGDC Framework data through Web Feature Service and 
GML 3.1.1 built upon GeoTools.  We understand that a major portion of 
this work will be contributed back to the GeoTools project, as a generic 
Web Feature Service client capable of handling WFS 1.1 and at the very 
least the required FGDC Framework data layers.


 We believe that the WFS 1.1 datastore and GML 3.1.1 parser built by 
The Open Planning Project with funding from Cooperative Agreement 
Program will be widely used, not just in the uDig client targeted by the 
grant, but also by any other Java-based project.  Additionally it will 
allow an improvement in the core Feature Model to handle the Framework 
Application schemas, which has long been a goal of the GeoTools 
community - to be the best parser and toolkit for handling complex GML 
and putting it in to a useful object model.  We believe this work have 
an large impact past the immediate funding, as GeoTools is liberally 
licensed to allow for even commercial implementations to build upon the 
same library.


The GeoTools community pledges to continue to maintain the work 
completed for the grant, making it available to any potential users of 
the library for the indefinite future.  The GeoTools Project Steering 
Committee also agrees to assist The Open Planning Project in integration 
to the core library, offering code reviews and advice to make sure that 
it becomes a core part of the library.  TOPP has long been a core 
contributor to the GeoTools Project, and we anticipate a very healthy 
working relationship.


<gives their full endorsement to this project.  When the project is 
completed OSGeo will promote the work done as part of the Cooperative 
Agreement Program to the members of the wider open source geospatial 
community.  The board is pleased to see this work taking place, and 
believes it has the potential to have a large impact not only in the 
open source world, but in the geospatial software world in general>>.


Sincerely,

The GeoTools Project Steering Committee.

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] RasterSymbolizer, where we are, where we want to go. (WAS: Re: [Geoserver-devel] problem styling tiff coverages)

[Chris Holmes]

o give a summary of what I tried and hope it rings a
>> bell somewhere...
>>
>> - Applying a style (like dem.sld, raster.sld, or a customized 
version of

>> one of those) *does* work on the supplied gtopo30 sample raster;
>
> I confirm that :-).
>
>> - Applying a style (idem) on my custom coverage does *not* work; the
>> raster gets rendered in grayscale, whatever I try. This raster is a
>> single band, tiled, Int32 geotiff, no colortable;
>> - Applying a style (idem) on a geotiff version (non-tiled, uint16, 1
>> band, no colortable) of the gtopo30_sample (created with 
gdal_translate)

>> does *not* work, neither does a baseline tiff with tfw file version;
>> - Applying a style to a fresh copy of the gtopo30 sample dataset
>> (created new dir with these files, created new coverageDataset, create
>> new Coverage) *does* work;
>>
>> This is what I could think of to narrow down the problem, and leads me
>> to the following conclusion: styling does not work for tiff files. I
>> might be wrong and it sounds kind of illogical (why would it not work
>> for tiffs, but work for gtopo30 rasters, while I suppose that the
>> rendering chain is basically the same except for the file reader...),
>> but I have no idea how to investigate this any further. So I hope some
>> of the imaging/wcs guru's can shed some light on this (and fix it, I
>> hope :)).
>>
>
> <>
> Ok, here is where we are with raster symbolizer.
>
> Honestly, the actual support for SLD+RasterSymbolizer is quite poor.
> It came out as a quick (real quick) hack for a live demonstration we
> had to give back in April 2006 and it was tested only on a few
> sources, between the others gtopo30 (data type SHORT) and arcgrid
> (data type FLOAT). Hence no surprises it does not do his job on some
> different data types.
>
> <>
> We are putting together in the background some test-cases in order to
> improve the RasterSymbolizer support. We aim to implement most part of
> what's in the SLD specification, even if the minimum goal is to have
> channel selection and color map working on most Java datatypes (int,
> float, short. byte).
>
> About timing:
> I am willing to put on this a certain amount of volunteering time
> (well, to be honest we are already doing the preparation work in the
> background as a volunteer effort we already have some the ColorMap SLD
> thing pretty much working).
>
> I have seen various people active on the mailing list and interested
> in this feature. So my idea/wish/suggestion is why don't we do
> something like I have seen doing on other OS projects and we launch
> like a sponsorship program for needs like this?
>
> This could be  an interesting test-case. There would be a proposal for
> an implementation and there would people could act as sponsorship
> giving some money, or giving some help with developing and or testing.
> This should allow us to achieve more for the projects in a more
> controlled fashion and hopefully in less time than having sparse
> separate efforts.
>
> What do people think about this? Am I completely crazy?
>
>
> Ciao,
> Simone.
>
>
>> Some additional info: using sun jdk 1.5.0-09, jai and jai-imageio from
>> cvs (synced yesterday), geotools (2.3.x branch) from svn (yesterday),
>> geoserver svn trunk from yesterday, deployed in tomcat-5.5.
>>
>>
>> Cheers from a bit desparate Vincent (I /do/ need raster styling...).
>>
>> 
-

>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> 
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

>>
>> ___
>> Geoserver-devel mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to 
share your

opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel






--
Chris Holmes
The Open Planning Project
http://topp.openplans.org