[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
Discussions
Subject: Re: [OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial
environment 'sizing')
IMO:
Paul,
On Feb 21, 2008, at 4:19 PM, [EMAIL PROTECTED] wrote:
What it comes down to is what is appropriate for your use case.
Indeed! However, there seem to be vanishingly few use cases
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
___
Discuss
IMO:
Hi Tyler,
Thanks for the reply.
Am I correct in believing that the two things people desire with
images in an RDB, is having an abstract 1) storage framework
(tables) and
2) a common access language (SQL) for managing the
framework. You could have the most complex storage
[EMAIL PROTECTED] wrote:
IMO:
Hi Tyler,
Thanks for the reply.
Am I correct in believing that the two things people desire with
images in an RDB, is having an abstract 1) storage framework
(tables) and
2) a common access language (SQL) for managing the
framework. You could have the
All too often, the benefits touted for raster-in-database have
nothing to do with the database, and everything to do with the data
preparation tools that the vendor is including with their raster-in-
database solution.
To store rasters in a database, you need a set of tools that will (a)
On Thu, 2008-02-21 at 16:24 -0800, Paul Ramsey wrote:
On Feb 21, 2008, at 4:19 PM, [EMAIL PROTECTED] wrote:
What it comes down to is what is appropriate for your use case.
Indeed! However, there seem to be vanishingly few use cases for which
raster-in-database is actually the more
IMO:
Paul,
On Feb 21, 2008, at 4:19 PM, [EMAIL PROTECTED] wrote:
What it comes down to is what is appropriate for your use case.
Indeed! However, there seem to be vanishingly few use cases for which
raster-in-database is actually the more appropriate solution.
;-) I beg to
IMO:
Tim,
Would you like to expand on this?
Bruce
Completely off the wall thought, but what about using git?
Tim
Notice:
This email and any attachments may contain information that is personal,
confidential, legally privileged and/or copyright.No part of it should be
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial
environment 'sizing')
IMO:
Paul,
On Feb 21, 2008, at 4:19 PM, [EMAIL PROTECTED] wrote:
What it comes down to is what is appropriate for your use case.
Indeed! However, there seem
IMO
12 million records is teensy. Stuff it into PostGIS. It's the billion-
point LIDAR sets that leave me queasy, but I can't begin to think of a
reasonable architecture for that without learning more about how the
points are actually USED, which I really am not clear on at the moment.
IMO:
Hi Randy, Ivan and Arnulf,
I seem to have spawned another thread, moving away from my original post
and Randy's excellent response.
Sorry.
I've renamed this thread accordingly.
more below...
[EMAIL PROTECTED] wrote on 21/02/2008 02:38:13 AM:
Hi Ivan and Bruce,
I am curious
- When you consider the complexities that Google must be facing with GE
in trying to manage 256x256k tiles of imagery over the entire world, at
multiple pyramid layers and with constant revision of imagery, you can
soon see that a file based approach would lead to a major headache.
He he, I
On 20-Feb-08, at 4:29 PM, [EMAIL PROTECTED] wrote:
- When you consider the complexities that Google must be facing
with GE in trying to manage 256x256k tiles of imagery over the
entire world, at multiple pyramid layers and with constant revision
of imagery, you can soon see that a file
14 matches
Mail list logo
