RE: [OSGeo-Discuss] Raster data on RDBMS

[Lucena, Ivan]

Thanks Jason,

Those results that I reported attest the performance of GDAL tools. You could 
get completely different results if you use tools from other vendors, like XCI, 
ACXG1S and FM3 [1]. There are some options on how that could be implemented but 
I believe we did some good choices in GDAL. 

Best regards,

Ivan

[1] - These names were mixed on purpose ;)

>  ---Original Message---
>  From: Jason Birch <[EMAIL PROTECTED]>
>  Subject: RE: [OSGeo-Discuss] Raster data on RDBMS
>  Sent: Oct 29 '08 15:09
>  
>  I find this stuff fascinating, but I believe that the Oracle EULA prohibits 
> users from disclosing the results of benchmark tests.  Be careful how you 
> represent these results.
>  
>  Jason
>  
>  -Original Message-
>  From: Lucena, Ivan
>  Subject: [OSGeo-Discuss] Raster data on RDBMS
>  
>  I would like to return to a discussion that we had months ago about raster 
> on RDBMS. But this time I would like to present some number.
>  
>  
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] methods for programatically adding fields to shapefiles

[P Kishor]

On 10/29/08, David Bianco <[EMAIL PROTECTED]> wrote:
> I have experience using Perl and the DBI module to do work like this.  I've
> read from dbf files in the past, but have not written to one.  Still, I see
> no reason why it would be a hangup.Let me know if you'd like to go in
> that direction.

Don't need DBI for this. Just Xbase will do the job in seconds (or
less). Keep in mind, there are two Xbases... one is called XBase and
is part of DBD::XBase, while the other is called just Xbase. I have
used XBase (without any of the DBD hangups), and it is lightning fast
in creating dbf files.




>
> Dave
>
>
>
> On Wed, Oct 29, 2008 at 4:56 PM, Alex Mandel <[EMAIL PROTECTED]>
> wrote:
> >
> > Tyler Erickson wrote:
> >
> > > I am interested in approaches for adding a populated field to a
> shapefile
> > > (for example, adding a new field named 'source_url' with the value
> > > 'http://somewebsite.com').  I would like to do this for several thousand
> > > files.
> > >
> > > At first I thought that I might be able to accomplish it using ogr2org
> with
> > > a sql clause, such as:
> > >
> > > ogr2ogr -sql "select *, 'http://somewebsite.com' as source_url from
> infile"
> > > outfile.shp infile.shp
> > >
> > > but that didn't work since ogr2ogr supports a limited set of SQL,
> described
> > > at:
> > > http://www.gdal.org/ogr/ogr_sql.html
> > >
> > > Any ideas on how to accomplish this? (I would prefer suggestions that
> can be
> > > scripted with python.)
> > >
> > > - Tyler
> > >
> >
> > Open a data connection the dbf with python, add a field to the properties
> of the table and populate the field.
> >
> > There are several ways to connect to a dbf depending on the OS, you could
> use an ODBC connector, or use some other type of dbf driver.
> > I haven't looked closely but there might be a dbf driver in the ogr python
> bindings already.
> >
> > I think my quick fix was to use python windows tools to wrap the dbf com
> object as a python object I could call, but that was a quick a dirty
> solution on windows.
> >
> > The other thing I've done is to create a blank shapefile with the exact
> same scheme + one field. Do an ogr2ogr -f "ESRI Shapefile" -a (append) of
> the blank shapefile and your existing one, and now you have a new field.
> >
> > Alex
> >
> >
> >
> > ___
> > Discuss mailing list
> > Discuss@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/discuss
> >
>
>
> ___
>  Discuss mailing list
>  Discuss@lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss
>
>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/
Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] methods for programatically adding fields to shapefiles

[David Bianco]

I have experience using Perl and the DBI module to do work like this.  I've
read from dbf files in the past, but have not written to one.  Still, I see
no reason why it would be a hangup.Let me know if you'd like to go in
that direction.

Dave


On Wed, Oct 29, 2008 at 4:56 PM, Alex Mandel <[EMAIL PROTECTED]>wrote:

> Tyler Erickson wrote:
>
>> I am interested in approaches for adding a populated field to a shapefile
>> (for example, adding a new field named 'source_url' with the value
>> 'http://somewebsite.com').  I would like to do this for several thousand
>> files.
>>
>> At first I thought that I might be able to accomplish it using ogr2org
>> with
>> a sql clause, such as:
>>
>> ogr2ogr -sql "select *, 'http://somewebsite.com' as source_url from
>> infile"
>> outfile.shp infile.shp
>>
>> but that didn't work since ogr2ogr supports a limited set of SQL,
>> described
>> at:
>> http://www.gdal.org/ogr/ogr_sql.html
>>
>> Any ideas on how to accomplish this? (I would prefer suggestions that can
>> be
>> scripted with python.)
>>
>> - Tyler
>>
>
> Open a data connection the dbf with python, add a field to the properties
> of the table and populate the field.
>
> There are several ways to connect to a dbf depending on the OS, you could
> use an ODBC connector, or use some other type of dbf driver.
> I haven't looked closely but there might be a dbf driver in the ogr python
> bindings already.
>
> I think my quick fix was to use python windows tools to wrap the dbf com
> object as a python object I could call, but that was a quick a dirty
> solution on windows.
>
> The other thing I've done is to create a blank shapefile with the exact
> same scheme + one field. Do an ogr2ogr -f "ESRI Shapefile" -a (append) of
> the blank shapefile and your existing one, and now you have a new field.
>
> Alex
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] methods for programatically adding fields to shapefiles

[Alex Mandel]

Tyler Erickson wrote:

I am interested in approaches for adding a populated field to a shapefile
(for example, adding a new field named 'source_url' with the value
'http://somewebsite.com').  I would like to do this for several thousand
files.

At first I thought that I might be able to accomplish it using ogr2org with
a sql clause, such as:

ogr2ogr -sql "select *, 'http://somewebsite.com' as source_url from infile"
outfile.shp infile.shp

but that didn't work since ogr2ogr supports a limited set of SQL, described
at:
http://www.gdal.org/ogr/ogr_sql.html

Any ideas on how to accomplish this? (I would prefer suggestions that can be
scripted with python.)

- Tyler


Open a data connection the dbf with python, add a field to the 
properties of the table and populate the field.


There are several ways to connect to a dbf depending on the OS, you 
could use an ODBC connector, or use some other type of dbf driver.
I haven't looked closely but there might be a dbf driver in the ogr 
python bindings already.


I think my quick fix was to use python windows tools to wrap the dbf com 
object as a python object I could call, but that was a quick a dirty 
solution on windows.


The other thing I've done is to create a blank shapefile with the exact 
same scheme + one field. Do an ogr2ogr -f "ESRI Shapefile" -a (append) 
of the blank shapefile and your existing one, and now you have a new field.


Alex
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] methods for programatically adding fields to shapefiles

[Tyler Erickson]

I am interested in approaches for adding a populated field to a shapefile
(for example, adding a new field named 'source_url' with the value
'http://somewebsite.com').  I would like to do this for several thousand
files.

At first I thought that I might be able to accomplish it using ogr2org with
a sql clause, such as:

ogr2ogr -sql "select *, 'http://somewebsite.com' as source_url from infile"
outfile.shp infile.shp

but that didn't work since ogr2ogr supports a limited set of SQL, described
at:
http://www.gdal.org/ogr/ogr_sql.html

Any ideas on how to accomplish this? (I would prefer suggestions that can be
scripted with python.)

- Tyler
-- 
View this message in context: 
http://n2.nabble.com/methods-for-programatically-adding-fields-to-shapefiles-tp1395535p1395535.html
Sent from the OSGeo Discuss mailing list archive at Nabble.com.

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Raster data on RDBMS

[Sylvan Ascent Inc.]

I understand. It is the difference between having to (1)serve fixed size tiles 
really fast out to GEarth/OpenLayers/etc, or (2) having to provide a random 
image or derivation thereof in any size, format, projection(WCS?). In the 
second case, speeding up the backend is the only way, in the first case, a tile 
cache could be a better choice. 
 
There is another possibility, that of putting a self-building cache on the 
backend, between the raw datastore and the WCS server, it could even be a 
database with some PGChip scheme.
 
<>
 
It may be faster from the db, as you can leverage the spatial index, and only 
pull the tiles you need, but I think Frank can answer this better.
 
I'm currently most interested in the first case of serving tiles, so if anyone 
has ideas on best practice for this, that would be great.
 
Roger Bedell, President Sylvan Ascent Inc.



From: [EMAIL PROTECTED] on behalf of G. Allegri
Sent: Wed 10/29/2008 12:50 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Raster data on RDBMS



Thanks everyone for this interesting thread. I think the two
approaches have different goals:

 - rendering-on-demand performance comparison
 - raster serving performance comparison

Both are of interest, but they shouldn't be confused.
It might be helpful to write a wiki page (or something else) where to
gather the "best-practices" on serving (big) rasters. Well, it could
be interesting for vectors too, but it's a different story.
It's a common task for many of us, and it would be of help for both
the newbies and the more experienced users...
Ok, sorry for this OT digression :)

2008/10/29 Frank Warmerdam <[EMAIL PROTECTED]>:
> Sylvan Ascent Inc. wrote:
>>
>> I think, that since the goal of all this storage of pyramids and the like
>> is
>> just to get speed, that they aren't apples/oranges, but apples apples,
>> since
>> they are both pyramid schemes, just in different places, either in front,
>> or
>> in back of the server.
>
> Roger,
>
> My point is that a tile caching approach is really comparing tile caching
> performance to rendering-on-demand performance while I think the original
> point was that rendering-from-database and rendering-from-filesystem could
> have similar performance for input raster data.
>
> Your comparison is also of interest but I don't think it is fair to compare
> rendering from Oracle through MapServer (or GeoServer) to satisfying
> map requests directly from a tile cache.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> [EMAIL PROTECTED]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


<>___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Alex Mandel]

Hmm, I went to that session last year and ran into Ming Tsou several 
times throughout the conference, maybe I can work out some sort of 
collaboration with him, so that if you don't switch sessions we can at 
least announce each others sessions and do PR together.


Thanks,
Alex

Eric Wolf wrote:

I'll have to run that by the boss. Since you are tied to CISG, it'll be
easier. I am supposed to be presenting in Ming Tsou's session "Internet
GIS, Virtual Globes, and related Cartographic Research".
-Eric

On Wed, Oct 29, 2008 at 11:38 AM, Alex Mandel <[EMAIL PROTECTED]>wrote:


Eric Wolf wrote:



I'm about to submit my abstract to the AAG conference on comparing
available distributed geospatial technologies for the USGS National Map.
Of
course, I haven't really even started the footwork...

I'd be very interested to see other people's benchmarks.

-Eric



Eric,

Would you be interested in joining our session on FOSS GIS? We're still
looking for some more talks, and now have the backing of the AAG
Cyberinfrastructure group which should ensure a good crowd of techies.

http://wiki.osgeo.org/wiki/AAG_2009

Thanks,
Alex




___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Raster data on RDBMS

[Lucena, Ivan]

Frank,

>  My point is that a tile caching approach is really comparing tile caching
>  performance to rendering-on-demand performance while I think the original
>  point was that rendering-from-database and rendering-from-filesystem could
>  have similar performance for input raster data.

D'accord.

>  Your comparison is also of interest but I don't think it is fair to compare
>  rendering from Oracle through MapServer (or GeoServer) to satisfying
>  map requests directly from a tile cache.

I shouldn't have mentioned MapServer. Web-serving wasn't my point to beginning 
with. I can gdal_translate from 
the georaster driver to vrt and open the result on OpenEV. That gives me a good 
idea of how the driver perform in 
a rendering environment. I would need to change OpenEV do it directly. But by 
doing that I would be testing GDAL 
not Oracle. To see Oracle Georaster in action I can use some freeviewer (free 
as in gratis). That is not my point.

The real point is should we discard RDBMS for Raster storage just because we 
are sure that there will be overhead, 
ours direct fopen(), fread() will always be faster? Myth or fact? Those tests 
have proven otherwise so the question 
is what is going own?

I messed around with some free-open-source RDBMS a long time ago (last century 
actually), checking out how to 
create type extension. But I would not imagine getting into to the core of how 
does things work just for the fun of 
it. So, the only thing I can do is to check the results from the outside and 
Oracle+GDAL/GeoRaster is the 
environment that let me do that because they let you use the software without a 
license, as long it is not on 
production mode. 

I should test mySQL+TerraLib or PostGIS+GDAL/PGCHIP also. Maybe.

Best regards,

Ivan

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Eric Wolf]

I'll have to run that by the boss. Since you are tied to CISG, it'll be
easier. I am supposed to be presenting in Ming Tsou's session "Internet
GIS, Virtual Globes, and related Cartographic Research".
-Eric

On Wed, Oct 29, 2008 at 11:38 AM, Alex Mandel <[EMAIL PROTECTED]>wrote:

> Eric Wolf wrote:
>
>> 
>> I'm about to submit my abstract to the AAG conference on comparing
>> available distributed geospatial technologies for the USGS National Map.
>> Of
>> course, I haven't really even started the footwork...
>>
>> I'd be very interested to see other people's benchmarks.
>>
>> -Eric
>>
>>
> Eric,
>
> Would you be interested in joining our session on FOSS GIS? We're still
> looking for some more talks, and now have the backing of the AAG
> Cyberinfrastructure group which should ensure a good crowd of techies.
>
> http://wiki.osgeo.org/wiki/AAG_2009
>
> Thanks,
> Alex
>
>
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>



-- 
-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf  720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Alex Mandel]

Eric Wolf wrote:


I'm about to submit my abstract to the AAG conference on comparing
available distributed geospatial technologies for the USGS National Map. Of
course, I haven't really even started the footwork...

I'd be very interested to see other people's benchmarks.

-Eric



Eric,

Would you be interested in joining our session on FOSS GIS? We're still 
looking for some more talks, and now have the backing of the AAG 
Cyberinfrastructure group which should ensure a good crowd of techies.


http://wiki.osgeo.org/wiki/AAG_2009

Thanks,
Alex


___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Eric Wolf]

I'm about to submit my abstract to the AAG conference on comparing
available distributed geospatial technologies for the USGS National Map. Of
course, I haven't really even started the footwork...

I'd be very interested to see other people's benchmarks.

-Eric

On Wed, Oct 29, 2008 at 10:55 AM, Markus Neteler <[EMAIL PROTECTED]> wrote:

> Bob, all,
>
> On Wed, Oct 29, 2008 at 5:12 PM, Bob Basques
> <[EMAIL PROTECTED]> wrote:
> > Markus,
> >
> > What's all that stuff in there about managed and un-managed supposed to
> describe?
> > Seems to be somewhat out of date.  I think I would start over with the
> whole bottom section.
>
> sounds good! :)
>
> In general, it's neither my field nor my document - so I would leave it to
> others. I consider myself as future "consumer" of such a guide.
>
> In general, as Frank says, it is hard to write comparative studies.
> As user, I would hope to receive some guidance to navigate in our
> software offers - see our logo motto! That's "all".
>
> Best
> Markus
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>



-- 
-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf  720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Markus Neteler]

Bob, all,

On Wed, Oct 29, 2008 at 5:12 PM, Bob Basques
<[EMAIL PROTECTED]> wrote:
> Markus,
>
> What's all that stuff in there about managed and un-managed supposed to 
> describe?
> Seems to be somewhat out of date.  I think I would start over with the whole 
> bottom section.

sounds good! :)

In general, it's neither my field nor my document - so I would leave it to
others. I consider myself as future "consumer" of such a guide.

In general, as Frank says, it is hard to write comparative studies.
As user, I would hope to receive some guidance to navigate in our
software offers - see our logo motto! That's "all".

Best
Markus
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Raster data on RDBMS

[G. Allegri]

Thanks everyone for this interesting thread. I think the two
approaches have different goals:

 - rendering-on-demand performance comparison
 - raster serving performance comparison

Both are of interest, but they shouldn't be confused.
It might be helpful to write a wiki page (or something else) where to
gather the "best-practices" on serving (big) rasters. Well, it could
be interesting for vectors too, but it's a different story.
It's a common task for many of us, and it would be of help for both
the newbies and the more experienced users...
Ok, sorry for this OT digression :)

2008/10/29 Frank Warmerdam <[EMAIL PROTECTED]>:
> Sylvan Ascent Inc. wrote:
>>
>> I think, that since the goal of all this storage of pyramids and the like
>> is
>> just to get speed, that they aren't apples/oranges, but apples apples,
>> since
>> they are both pyramid schemes, just in different places, either in front,
>> or
>> in back of the server.
>
> Roger,
>
> My point is that a tile caching approach is really comparing tile caching
> performance to rendering-on-demand performance while I think the original
> point was that rendering-from-database and rendering-from-filesystem could
> have similar performance for input raster data.
>
> Your comparison is also of interest but I don't think it is fair to compare
> rendering from Oracle through MapServer (or GeoServer) to satisfying
> map requests directly from a tile cache.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> [EMAIL PROTECTED]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Raster data on RDBMS

[Frank Warmerdam]

Sylvan Ascent Inc. wrote:

I think, that since the goal of all this storage of pyramids and the like is
just to get speed, that they aren't apples/oranges, but apples apples, since
they are both pyramid schemes, just in different places, either in front, or
in back of the server.


Roger,

My point is that a tile caching approach is really comparing tile caching
performance to rendering-on-demand performance while I think the original
point was that rendering-from-database and rendering-from-filesystem could
have similar performance for input raster data.

Your comparison is also of interest but I don't think it is fair to compare
rendering from Oracle through MapServer (or GeoServer) to satisfying
map requests directly from a tile cache.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit,now weening from BentleyMicroStation..looking toward FOSS4G

[Bob Basques]

Frank,

It sounds like we're both in the same boat then, too chicken to put something 
to paper (web).  I feel very comfortable talking about GeoMoose and MapServer 
and to some degree OpenLayers and PostGis, but that's about it.

Edting a section of page for each of these packages and how they 
react/integrate with each other would be where my comfort zone would be at.  
So, how do we get this type of documenting started?

I've thought about putting it on our GeoMoose pages, but then only the GeoMoose 
subscribers would see it, and not necessarily new folks that are seeing the 
light (so to speak) on the topic of Open Source.

Can some sort of list of packages with a sublist of connectible packages be 
generated somehow?  Something akin to WikiPedia but with OsGeo Focus?  Should 
WikiPedia be used as the end page possibly, where each package is described 
individually and cross referenced in a OSGEO page?

You may be able to tell that I've thought about this somewhat in the past . . . 
.  :c)

bobb




>>> Frank Warmerdam <[EMAIL PROTECTED]> 10/29/08 11:21 AM >>>
Bob Basques wrote:
> Markus,
> 
> What's all that stuff in there about managed and un-managed supposed to
> describe?  Seems to be somewhat out of date.  I think I would start over
> with the whole bottom section.
> 
> Another thing with this page is, I wouldn't feel comfortable goin g in there
> and changing anything without knowing the details about each package listed.
> I think a different approach is needed that reflects each package more
> directly.  I'm involved in the GeoMoose project for Example, which is a
> WebFront for MapServer ( and will be using OpenLayers LIBs in the near
> future as well).   I would prefer to describe each package separately along
> with how they interact.  Possibly as a spreadsheet to begin with.
> 
> Is this approariate for this page, or in some other ??

Bob,

I will say, that I think preparing a "which project to use" document is
fraught with peril. It is hard for anyone to have a really good picture of
the strengths and weaknesses of all the packages.  Even if the result is
"fair" it is inevitably going to ruffle feathers in some projects who may
feel it is unfair.

I applaud efforts to prepare a document - I'm just too chicken (and
unknowledgable) to do it myself!

Best regards,
-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit,now weening from Bentley MicroStation..looking toward FOSS4G

[Frank Warmerdam]

Bob Basques wrote:

Markus,

What's all that stuff in there about managed and un-managed supposed to
describe?  Seems to be somewhat out of date.  I think I would start over
with the whole bottom section.

Another thing with this page is, I wouldn't feel comfortable goin g in there
and changing anything without knowing the details about each package listed.
I think a different approach is needed that reflects each package more
directly.  I'm involved in the GeoMoose project for Example, which is a
WebFront for MapServer ( and will be using OpenLayers LIBs in the near
future as well).   I would prefer to describe each package separately along
with how they interact.  Possibly as a spreadsheet to begin with.

Is this approariate for this page, or in some other ??


Bob,

I will say, that I think preparing a "which project to use" document is
fraught with peril. It is hard for anyone to have a really good picture of
the strengths and weaknesses of all the packages.  Even if the result is
"fair" it is inevitably going to ruffle feathers in some projects who may
feel it is unfair.

I applaud efforts to prepare a document - I'm just too chicken (and
unknowledgable) to do it myself!

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Raster data on RDBMS

[Sylvan Ascent Inc.]

Hi Frank,
I'm not sure I completely agree about your apples/oranges, here's why:
 
We are in the process of putting together a big raster server, so I'm 
evaluating the best way to proceed. I'm quite familiar with putting raster 
tiles in a database, did that way back in the last century. I've decided to use 
Geoserver, since we need (want)  WFS-T and WCS, and the latest speed race 
between MapServer and GeoServer seems to be a tie more or less.
 
As I see it we have several options:
 
1) Put the big original raster images in back of Geoserver, access using their 
Mosaic and the GDAL based ImageIO-ext.
Advantage - easy, but kind of slow.
 
2) Take the originals and build a file-based pyramid
Advantage - faster, but a lot of work, plus duplication and tricky to keep 
updated as new data comes in.
 
3) Take the originals and build a PostGIS based pyramid.
Likely, about the same as 3 in speed and work and duplication.
 
4) Do 1, but put a pyramiding tileserver in front. It builds the pyrimid in 2 
and 3 over time, and is likely the fastest if you hit the cache, and is no 
harder to do than #1.
 
I think, that since the goal of all this storage of pyramids and the like is 
just to get speed, that they aren't apples/oranges, but apples apples, since 
they are both pyramid schemes, just in different places, either in front, or in 
back of the server. 
 
Roger Bedell, President Sylvan Ascent Inc.
800-362-8971
+34 626 855 662
[EMAIL PROTECTED]  
www.sylvanascent.com  
www.topodepot.com  



From: [EMAIL PROTECTED] on behalf of Frank Warmerdam
Sent: Wed 10/29/2008 10:43 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Raster data on RDBMS



Sylvan Ascent Inc. wrote:
> Mike and Ivan,
>
> I'd like to see them also compared to a caching solution, like GeoWebCache,
> or TileCache. These effectively create a file-based "database" of little
> bitty tiles at certain resolutions, kind of like a tile pyrimid that is
> created gradually over time as the image data is accessed.
>
> One would think the file-based cache system would be faster than a similar
> database solution, with the database solution giving no real benefits that I
> can see.

Roger,

While it might be educational to compare to a tilecache solution it is really
comparing apples and oranges.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


<>___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit,now weening from Bentley MicroStation..looking toward FOSS4G

[Bob Basques]

Markus,

What's all that stuff in there about managed and un-managed supposed to 
describe?  Seems to be somewhat out of date.  I think I would start over with 
the whole bottom section.

Another thing with this page is, I wouldn't feel comfortable goin g in there 
and changing anything without knowing the details about each package listed.  I 
think a different approach is needed that reflects each package more directly.  
I'm involved in the GeoMoose project for Example, which is a WebFront for 
MapServer ( and will be using OpenLayers LIBs in the near future as well).   I 
would prefer to describe each package separately along with how they interact.  
Possibly as a spreadsheet to begin with.

Is this approariate for this page, or in some other ??

Thanks

bobb



>>> "Markus Neteler" <[EMAIL PROTECTED]> 10/29/08 11:03 AM >>>
On Wed, Oct 29, 2008 at 4:56 PM, Judit Mays <[EMAIL PROTECTED]> wrote:
> pyroGIS schrieb:
>> Fellow listers,
>>
>> Where I'm wondering about going next is down
>> the whole Web Mapping road. What are your opinions on GeoServer vs.
>> MapServer vs. OpenLayers? Those seem to get the most love from the OS
>> community ... should I skip worldKit? what about deegree?
>>
>
> Hello Joe,
> if you are interested in a large community you might find MapServer and
> GeoServer more appealing than deegree. I can't say much more about the
> first two, as I've never used either. But there has been a presentation
> comparing GeoServer and MapServer at the last FOSS4G. You will probably
> find the slides online.

Suggestion - what about getting this page updated with comments
from this thread:
  http://wiki.osgeo.org/wiki/Choosing_a_Web_Mapping_Platform

Don't hesitate to modify the Wiki page!

Cheers,
Markus
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Markus Neteler]

On Wed, Oct 29, 2008 at 4:56 PM, Judit Mays <[EMAIL PROTECTED]> wrote:
> pyroGIS schrieb:
>> Fellow listers,
>>
>> Where I'm wondering about going next is down
>> the whole Web Mapping road. What are your opinions on GeoServer vs.
>> MapServer vs. OpenLayers? Those seem to get the most love from the OS
>> community ... should I skip worldKit? what about deegree?
>>
>
> Hello Joe,
> if you are interested in a large community you might find MapServer and
> GeoServer more appealing than deegree. I can't say much more about the
> first two, as I've never used either. But there has been a presentation
> comparing GeoServer and MapServer at the last FOSS4G. You will probably
> find the slides online.

Suggestion - what about getting this page updated with comments
from this thread:
  http://wiki.osgeo.org/wiki/Choosing_a_Web_Mapping_Platform

Don't hesitate to modify the Wiki page!

Cheers,
Markus
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] kicked the ESRI habit, now weening from Bentley MicroStation..looking toward FOSS4G

[Judit Mays]

pyroGIS schrieb:
> Fellow listers,
> 
> Where I'm wondering about going next is down
> the whole Web Mapping road. What are your opinions on GeoServer vs.
> MapServer vs. OpenLayers? Those seem to get the most love from the OS
> community ... should I skip worldKit? what about deegree?
> 

Hello Joe,
if you are interested in a large community you might find MapServer and
GeoServer more appealing than deegree. I can't say much more about the
first two, as I've never used either. But there has been a presentation
comparing GeoServer and MapServer at the last FOSS4G. You will probably
find the slides online.

The deegree community is not quite as large (yet), but we are about to
change that. So you are very welcome to join in. And you are also more
than welcome to improve the documentation and /or wiki contents ;-)
Support on our mailing lists is already very good, so no need to worry
about the community.

As for hitting the Web Mapping road with deegree, I can only say: sure,
go ahead, not a problem. But instead of writing down all the details
here, I added it to the deegree wiki, so more people might benefit from it.
To get an impression of what is possible with deegree WMS (besides the
obvious: getting maps from a server) please go to
https://wiki.deegree.org/deegreeWiki/WebServices#WMS

Cheers,
Judit
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] ES Local Chapter subdomain

[Venkatesh Raghavan]

Frank Warmerdam wrote:
...


Yves and Venka,

The jp and fr subdomain rewrites have been put in place.  If anyone else
wants one it is safer to file a SAC Trac ticket to ensure the request 
doesn't

get lost in the email stream.


Thanks Frank.
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Raster data on RDBMS

[Jason Birch]

I find this stuff fascinating, but I believe that the Oracle EULA prohibits 
users from disclosing the results of benchmark tests.  Be careful how you 
represent these results.

Jason

-Original Message-
From: Lucena, Ivan
Subject: [OSGeo-Discuss] Raster data on RDBMS

I would like to return to a discussion that we had months ago about raster on 
RDBMS. But this time I would like to present some number.

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] ES Local Chapter subdomain

[Jacolin Yves]

Le Wednesday 29 October 2008 15:52:16 Frank Warmerdam, vous avez écrit :
> If anyone else
> wants one it is safer to file a SAC Trac ticket to ensure the request
> doesn't get lost in the email stream.

Hum, you are right, I forget this! Sorry.

Thanks anyway!

Y.
-- 
Yves Jacolin
---
http://softlibre.gloobe.org
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] ES Local Chapter subdomain

[Frank Warmerdam]

Jacolin Yves wrote:

Le Wednesday 29 October 2008 03:23:33 Venkatesh Raghavan, vous avez écrit :

Would it be possible to create a DNS entry jp.osgeo.org pointing to
www.osgeo.jp

Regards

Venka
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Hi,

I am interested for the same thing for fr.osgeo.org pointing to 
http://wiki.osgeo.org/wiki/Francophone as www.osgeo.fr does.


Yves and Venka,

The jp and fr subdomain rewrites have been put in place.  If anyone else
wants one it is safer to file a SAC Trac ticket to ensure the request doesn't
get lost in the email stream.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Raster data on RDBMS

[Frank Warmerdam]

Sylvan Ascent Inc. wrote:

Mike and Ivan,

I'd like to see them also compared to a caching solution, like GeoWebCache,
or TileCache. These effectively create a file-based "database" of little
bitty tiles at certain resolutions, kind of like a tile pyrimid that is
created gradually over time as the image data is accessed.

One would think the file-based cache system would be faster than a similar
database solution, with the database solution giving no real benefits that I
can see.


Roger,

While it might be educational to compare to a tilecache solution it is really
comparing apples and oranges.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Raster data on RDBMS

[Sylvan Ascent Inc .]

Mike and Ivan,
 
I'd like to see them also compared to a caching solution, like GeoWebCache, or 
TileCache. These effectively create a file-based "database" of little bitty 
tiles at certain resolutions, kind of like a tile pyrimid that is created 
gradually over time as the image data is accessed.
 
One would think the file-based cache system would be faster than a similar 
database solution, with the database solution giving no real benefits that I 
can see.
 
>>>I basically agreed with that but
>>> after seeing how fragile and complicated even a well defined structure of
>>> folders and files could be I would vote in favor of the good and old
>>> relational model.
 
Since the cache is maintained by the software in a completely defined way, and 
never messed with by humans, I wonder what could go wrong?
 
Roger Bedell, Sylvan Ascent Inc.
800-362-8971
+34 626 855 662
[EMAIL PROTECTED]  



From: [EMAIL PROTECTED] on behalf of Smith, Michael ERDC-CRREL-NH
Sent: Wed 10/29/2008 10:13 AM
To: Lucena, Ivan; OSGeo Discussions; Paul Ramsey
Subject: Re: [OSGeo-Discuss] Raster data on RDBMS



Ivan,

Those numbers look impressive. We are just starting to set up some new
hardware here and I plan to do some testing also. Perhaps we can collaborate
and come up with a test suite in order to track these numbers across builds.

Mike


--
Michael Smith
RSGIS Center
ERDC - CRREL
US Army Corps of Engineers




On 10/29/08  1:35 AM, "Lucena, Ivan" <[EMAIL PROTECTED]> wrote:

> Paul,
>
> Good thought.
>
> Let's see. The default blocking used by the GeoRaster driver is (256, 256, 1).
> That is good because GeoTiffs doesn't tile on band space. So I would imagine
> that if I tiled the GeoTiff this way:
>
> [EMAIL PROTECTED]:~/Data> time gdal_translate Barcelona_2007_R2C2.TIF
> Barcelona_2007_R2C2_tiled.TIF -co BLOCKXSIZE=256 -co BLOCKYSIZE=256
> Input file size is 14336, 14336
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> real   0m42.991s
> user 0m20.289s
> sys   0m2.516s
>
> The comparison would be fair:
>
> [EMAIL PROTECTED]:~/Data> time gdal_translate Barcelona_2007_R2C2_tiled.TIF
> out2.tif -srcwin 0 0 2000 2000
> Input file size is 14336, 14336
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> real   0m1.604s
> user 0m1.156s
> sys  0m0.444s
>
> What do you think?
>
> I would imagine that if I run gdaladdo to add Pyramids on the GeoRaster one
> application could take advantage of it by telling Oracle to cache the BLOB in
> memory. So the next time a user zoom-in the performance would be even better.
>
> I am trying to setup a mapserver experiment on that issue but for now I would
> like to keep my analysis on that very simple process of extracting a subset.
>
> Best regards,
>
> Ivan
>
>
>>  ---Original Message---
>>  From: Paul Ramsey <[EMAIL PROTECTED]>
>>  Subject: Re: [OSGeo-Discuss] Raster data on RDBMS
>>  Sent: Oct 29 '08 05:00
>> 
>>  The data is chunked in Oracle into tiles, so unless you tile the TIFF
>>  as well you aren't really doing a direct comparison. Even if you end
>>  up with the same numbers for both processes, I'll still be impressed,
>>  since I assumed Oracle would have a higher overhead.
>> 
>>  P.
>> 
>>  On Tue, Oct 28, 2008 at 9:54 PM, Lucena, Ivan <[EMAIL PROTECTED]>
>> wrote:
>>> Hi There,
>>>
>>> I would like to return to a discussion that we had months ago about raster
>>> on RDBMS. But this time I would like to present some number.
>>>
>>> As long as I could recall there was basically two major arguments contrary
>>> to storing raster on RDBMS. One very pragmatical: "Why waste precious
>>> process time with the overhead of dealing with queries, tables, client-sever
>>> back and forth just to get the data from BLOB fields on a database when you
>>> can get it directly from the file system?". The other argument was
>>> semantical: "Why store raster on RDBMS if in general we are not expecting to
>>> have a transactions on that data?"
>>>
>>> I cannot argue against the second one. I basically agreed with that but
>>> after seeing how fragile and complicated even a well defined structure of
>>> folders and files could be I would vote in favor of the good and old
>>> relational model.
>>>
>>> That is my experiment. I downloaded two free data samples from Naveteq
>>> website. Two geotiff files with the same size and number of bands (14336,
>>> 14336,  3):
>>>
>>> [EMAIL PROTECTED]:~/Data> du -k Barcelona_2007_R2C2.TIF
>>> 602828  Barcelona_2007_R2C2.TIF
>>> [EMAIL PROTECTED]:~/Data> du -k San_Francisco_2006_R1C2.TIF
>>> 602828  San_Francisco_2006_R1C2.TIF
>>>
>>> Then I loaded those images to Oracle Spatial GeoRaster using GDAL. The
>>> loading process is comparable than some commercial ETL products on the
>>> market. It took about 2 minutes to load each image.
>>>
>>> [EMAIL PROTECTED]:~/Data> time gdal_translate -of georaster
>>> Barcelona_2007_R2C2.TIF georaster:scott,tiger,orcl,RDT_2$,2
>>> Input f

Re: [OSGeo-Discuss] Raster data on RDBMS

[Smith, Michael ERDC-CRREL-NH]

Ivan,

Those numbers look impressive. We are just starting to set up some new
hardware here and I plan to do some testing also. Perhaps we can collaborate
and come up with a test suite in order to track these numbers across builds.

Mike


-- 
Michael Smith
RSGIS Center
ERDC - CRREL
US Army Corps of Engineers




On 10/29/08  1:35 AM, "Lucena, Ivan" <[EMAIL PROTECTED]> wrote:

> Paul,
> 
> Good thought. 
> 
> Let's see. The default blocking used by the GeoRaster driver is (256, 256, 1).
> That is good because GeoTiffs doesn't tile on band space. So I would imagine
> that if I tiled the GeoTiff this way:
> 
> [EMAIL PROTECTED]:~/Data> time gdal_translate Barcelona_2007_R2C2.TIF
> Barcelona_2007_R2C2_tiled.TIF -co BLOCKXSIZE=256 -co BLOCKYSIZE=256
> Input file size is 14336, 14336
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> real   0m42.991s
> user 0m20.289s
> sys   0m2.516s
> 
> The comparison would be fair:
> 
> [EMAIL PROTECTED]:~/Data> time gdal_translate Barcelona_2007_R2C2_tiled.TIF
> out2.tif -srcwin 0 0 2000 2000
> Input file size is 14336, 14336
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> real   0m1.604s
> user 0m1.156s
> sys  0m0.444s
> 
> What do you think?
> 
> I would imagine that if I run gdaladdo to add Pyramids on the GeoRaster one
> application could take advantage of it by telling Oracle to cache the BLOB in
> memory. So the next time a user zoom-in the performance would be even better.
> 
> I am trying to setup a mapserver experiment on that issue but for now I would
> like to keep my analysis on that very simple process of extracting a subset.
> 
> Best regards,
> 
> Ivan
> 
> 
>>  ---Original Message---
>>  From: Paul Ramsey <[EMAIL PROTECTED]>
>>  Subject: Re: [OSGeo-Discuss] Raster data on RDBMS
>>  Sent: Oct 29 '08 05:00
>>  
>>  The data is chunked in Oracle into tiles, so unless you tile the TIFF
>>  as well you aren't really doing a direct comparison. Even if you end
>>  up with the same numbers for both processes, I'll still be impressed,
>>  since I assumed Oracle would have a higher overhead.
>>  
>>  P.
>>  
>>  On Tue, Oct 28, 2008 at 9:54 PM, Lucena, Ivan <[EMAIL PROTECTED]>
>> wrote:
>>> Hi There,
>>> 
>>> I would like to return to a discussion that we had months ago about raster
>>> on RDBMS. But this time I would like to present some number.
>>> 
>>> As long as I could recall there was basically two major arguments contrary
>>> to storing raster on RDBMS. One very pragmatical: "Why waste precious
>>> process time with the overhead of dealing with queries, tables, client-sever
>>> back and forth just to get the data from BLOB fields on a database when you
>>> can get it directly from the file system?". The other argument was
>>> semantical: "Why store raster on RDBMS if in general we are not expecting to
>>> have a transactions on that data?"
>>> 
>>> I cannot argue against the second one. I basically agreed with that but
>>> after seeing how fragile and complicated even a well defined structure of
>>> folders and files could be I would vote in favor of the good and old
>>> relational model.
>>> 
>>> That is my experiment. I downloaded two free data samples from Naveteq
>>> website. Two geotiff files with the same size and number of bands (14336,
>>> 14336,  3):
>>> 
>>> [EMAIL PROTECTED]:~/Data> du -k Barcelona_2007_R2C2.TIF
>>> 602828  Barcelona_2007_R2C2.TIF
>>> [EMAIL PROTECTED]:~/Data> du -k San_Francisco_2006_R1C2.TIF
>>> 602828  San_Francisco_2006_R1C2.TIF
>>> 
>>> Then I loaded those images to Oracle Spatial GeoRaster using GDAL. The
>>> loading process is comparable than some commercial ETL products on the
>>> market. It took about 2 minutes to load each image.
>>> 
>>> [EMAIL PROTECTED]:~/Data> time gdal_translate -of georaster
>>> Barcelona_2007_R2C2.TIF georaster:scott,tiger,orcl,RDT_2$,2
>>> Input file size is 14336, 14336
>>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>> Ouput dataset: (georaster:scott,tiger,orcl,RDT_2$,2) on GDAL_IMPORT,RASTER
>>> real  1m54.973s
>>> user 0m4.368s
>>> sys   0m1.936s
>>> 
>>> If you are a Oracle GeoRaster users you might be excited about those number
>>> already but those are not the numbers I want to show. What I would like to
>>> do is to compare the time that it takes to extract subset from the original
>>> geotiff and compare with the time to extract the same subset from the RDBMS.
>>> He are the numbers:
>>> 
>>> [EMAIL PROTECTED]:~/Data> time gdal_translate
>>> georaster:scott,tiger,orcl,RDT_2$,2 out.tif -srcwin 0 0 2000 2000
>>> Input file size is 14336, 14336
>>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>> real  0m0.720s
>>> user 0m0.408s
>>> sys   0m0.108s
>>> 
>>> [EMAIL PROTECTED]:~/Data> time gdal_translate Barcelona_2007_R2C2.TIF 
>>> out2.tif
>>> -srcwin 0 0 2000 2000
>>> Input file size is 14336, 14336
>>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>> real  0m1.177s
>>> user 0m0.976s
>>> sys   

Re: [OSGeo-Discuss] ES Local Chapter subdomain

[Jacolin Yves]

Le Wednesday 29 October 2008 03:23:33 Venkatesh Raghavan, vous avez écrit :
> Frank Warmerdam wrote:
> > Jorge,
> >
> > I foresee no problem in creating a DNS entry for es.osgeo.org and
> > pointing it whereever you like.
>
> Frank,
>
> Would it be possible to create a DNS entry jp.osgeo.org pointing to
> www.osgeo.jp
>
> Regards
>
> Venka
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss

Hi,

I am interested for the same thing for fr.osgeo.org pointing to 
http://wiki.osgeo.org/wiki/Francophone as www.osgeo.fr does.

Thanks,

Y.
-- 
Yves Jacolin
---
http://softlibre.gloobe.org
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss