On 2/22/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> IMO:
>
> Hi Puneet.
>
> Thanks for the comments.
>
>
>
> > That brings us back to PostGIS supporting images. Clearly, most folks
> > who use it don't see it worth the effort implementing. I suggest two
> > things --
> >
> > one. This
IMO:
Hi Puneet.
Thanks for the comments.
> That brings us back to PostGIS supporting images. Clearly, most folks
> who use it don't see it worth the effort implementing. I suggest two
> things --
>
> one. This being open source, Bruce and others, start developing the
> capabilities and contri
IMO:
Paulo,
When you have a look at the GeoSciML work, you'll see the types of
aspatial attributes that I'm referring to.
Bruce
>
> > - When it comes to modelling Geoscientific data, the variety and depth
of
> > inter-relationships of aspatial requirements is probably beyond the
ability
>
Hi everyone,
The OSGeo Journal team is currently working on our 4th volume.
Several people have approached me over the past few months, asking
how they can help. If you are wondering the same thing, one area
where we could use help is in reviewing and proof-reading articles.
We are just
On Feb 22, 2008, at 2:26 AM, Gilberto Camara wrote:
In corporate applications where vectors and raster live together,
and data processing and editing operations are used, handling
different types of data together in a database is convenient.
Control is more important than performance.
Agr
Hi,
I'm processing a dataset for the Cairngorms National Park in the UK.
This source is NextMap data at a 5 metre square gridded raster. It has
3 columns and 24000 rows. Amongst other things I calculate roughness
for kernels taking in all values within 64 celldistances. The roughness
output i
On 2/22/08, Gilberto Camara <[EMAIL PROTECTED]> wrote:
> Dear OSGEO
>
> I also beg to differ with Paul about the number of cases where image data
> handling in RDBMS is useful or necessary.
>
> In corporate applications where vectors and raster live together, and data
> processing and editing o
2008/2/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> By E&P, I'm assuming that you're referring to Exploration and Petroleum?
Exploration and Production, as is usual in the industry, sometimes
also referred as upstream
> I don't claim to be an expert, but I personally think that this is just
> ano
On Fri, 2008-02-22 at 10:49 +0900, Tim Bowden wrote:
> Bruce,
> Note: I've never tried this, and I'm making it up as I go. Others more
> informed than me may well kill the idea (Paul?).
Ok, kill this one. Tried it and it doesn't work.
Tim
___
Discus
Randy George wrote:
Hi Bruce,
"What approaches are people using with large Lidar datasets?"
You might take a look at the WeoGeo group. They are a commercial operation,
not FOSS,
BEEP!
The opposite to "FOSS" is "proprietary"! Some related information can be found
here:
http://wiki.o
[EMAIL PROTECTED] wrote:
IMO:
[...]
I am probably too vector oriented to understand the problems
involved here but my experience is that there should be no issue if
you have your services configured all right.
I don't agree. But then my requirements are for spatial data that covers a
la
Dear OSGEO
I also beg to differ with Paul about the number of cases where image data
handling in RDBMS is useful or necessary.
In corporate applications where vectors and raster live together, and data
processing and editing operations are used, handling different types of data
together in a
IMO:
Hello everyone,
Sorry for monopolising the list for the last day or so.
I think that I'll bring this to a close.
If anyone has anything to add, please email me off line.
To all who responded to this thread, thanks for helping me work through
these issues. It is good to know that ther
13 matches
Mail list logo
