Hi Stefan reading this email a bit more carefully (and seeing you CCed
our old budCameron) I am going to guess you want to set up an
unsupported module (please correct me if I am wrong! it would be rude of
me to make off with Lisasoft developers if you are only offering us the
code).
The long
Hi Stefan that sounds fun, sending an email like this is the first step
to getitng an "unsupported module" is that what you are after? If so I
will give the idea a solid +1, we will need to sort out things like svn
access etc.
Cheers,
Jody
Stefan Hansen wrote:
> Hi all!
>
> We have implemented
Hi Ecliesa, thanks for attending the meeting on monday it was was great
for everyone to hear about your module.
I have my first code donation for you; if you look at this wiki page:
- http://docs.codehaus.org/display/GEOTDOC/07+PostGIS+Lab
You can see a PostGISDialog connection parameter user in
Hi all!
We have implemented a datastore, which is supposed to be used in
Geoserver to aggregate the responses from several other WFS.
Our datastore uses the WFS-datastore to communicate with the cascaded
WFS (therefore, it is restricted to WFS 1.0). From the WFS-datastores
it retrieves responses
Justin Deoliveira wrote:
> You may have seen the massive commit I just made. I have indeed updated
> trunk to run against the recent changes made to the geoapi feature
> model. Thanks to everyone for feedback, especially Andrea and Adrian.
I am going to expand your list to include Gabriel and Rob f
Of course the moment I sent my last message I read this one (sigh). We
should talk on the geoapi list about if we want to maintain the
nogenerics jar or if we can quietly drop it...
Jody
> Hi all,
>
> I have deployed a new geoapi version so if you want to build trunk use
> -U next time you do.
Congrats Justin; nice to see this come together. Do we need to do a -U
to grab GeoAPI trunk? (You did deploy a GeoAPI SNAPSHOT did you not?)
Jody
> Hi all,
>
> You may have seen the massive commit I just made. I have indeed updated
> trunk to run against the recent changes made to the geoapi featu
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=383&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=382&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
Hi all,
I have deployed a new geoapi version so if you want to build trunk use
-U next time you do.
Also... this is not just any old geoapi update. I have updated trunk to
work against the normal geoapi jar (with generics). It required a few
minor changes to metadata, and referencing but all in a
Hi all,
You may have seen the massive commit I just made. I have indeed updated
trunk to run against the recent changes made to the geoapi feature
model. Thanks to everyone for feedback, especially Andrea and Adrian. I
think the end result has been a model with decent javadocs which is much
more a
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=376&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
On Tuesday 18 September 2007 18:58:49 Justin Deoliveira wrote:
> >> I would say to stay simple and consistent. I.e. no hacking at the
> >> geoserver side to match an unqualified "name" attribute to "gml:name".
> >> Same for location, etc.
> >> Rationale: gml:name has its semantic, and might be diff
Justin Deoliveira ha scritto:
>> Oh no, I totally agree with this. Only... we need the new UI and the new
>> config system before
>> tacking that!!! Uurrgggh :(
> Snif Snif... whats that I smell... a geoserver code sprint sometime next
> year to get the new UI done... smells good. (cough cough
Justin Deoliveira ha scritto:
> I can definitely see both sides here... I agree that a formal mapping is
> the "right" way to do it. However, for a simple case like I think that
> using a complex datastore may be overkill or an inconvenience. With the
> new feature model we should be able to suppor
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=371&projectId=81
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
> Oh no, I totally agree with this. Only... we need the new UI and the new
> config system before
> tacking that!!! Uurrgggh :(
Snif Snif... whats that I smell... a geoserver code sprint sometime next
year to get the new UI done... smells good. (cough cough cholmes)
:)
>
> Cheers
> Andrea
>
>>>
>> I would say to stay simple and consistent. I.e. no hacking at the
>> geoserver side to match an unqualified "name" attribute to "gml:name".
>> Same for location, etc.
>> Rationale: gml:name has its semantic, and might be different from the
>> "name" attribute of a single db table. If a
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=367&projectId=81
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=366&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
Rethink shapefile index generator
-
Key: GEOT-1498
URL: http://jira.codehaus.org/browse/GEOT-1498
Project: GeoTools
Issue Type: Improvement
Components: data shapefile
Affects Versions: 2.4-RC0
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=364&projectId=81
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=363&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
Le mardi 18 septembre 2007 à 10:30 +0200, Edgar Soldin a écrit :
> if bursa wolf parameters are missing, the parameters for an accurate
> ellipsoid shift are missing, so results will be (very?) inaccurate?
It depends on the source and target CRS, but there is typically an error
of about one kilome
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=361&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=360&projectId=81
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=359&projectId=86
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=358&projectId=1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070m
Not really ;) ...
after posting the snippet mentioned, i also had a look in your docs and
found the utility class, even posted about it in the list (see attachment).
once again .. respect to you geotools folks, you really made a nice
feature even more handy by creating the utility class.
just
Adrian,
true, true .. well told story that ... thanks alot.
just to make a point:
if bursa wolf parameters are missing, the parameters for an accurate
ellipsoid shift are missing, so results will be (very?) inaccurate?
kind regards ede
--
> Hey,
>
> In the "for dummies" collection, "geodesy for
Gabriel Roldán ha scritto:
> On Monday 17 September 2007 17:26:41 Justin Deoliveira wrote:
>
So simpleFeature.getAttribute("name") would indeed match content created
with a "gml:name" (the gml prefix internally would of been matched
against a
NameImpl("http://schemas.opengis.
http://geo.openplans.org:9090/continuum/buildResult.action?buildId=356&projectId=81
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070
On Monday 17 September 2007 17:26:41 Justin Deoliveira wrote:
> >> So simpleFeature.getAttribute("name") would indeed match content created
> >> with a "gml:name" (the gml prefix internally would of been matched
> >> against a
> >> NameImpl("http://schemas.opengis.net/gml/3.2.1/gml.xsd","name";).
>
Good: Looks like we may be able to allow normal codehaus users to edit
our wiki again...
Bad: Every single edit now requires you to type the word in the picture
Jody
-
This SF.net email is sponsored by: Microsoft
Defy all ch
34 matches
Mail list logo
