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 curi
- 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 base
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 storag
[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 mo
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)
IMO:
Hi Paul,
> 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 s
IMO:
Thanks for the reply Arnulf.
>
> I tell
> her that she has been brain washed by certain creative minds who
> "sell things" (instead of develop software) into thinking that files
> based systems are stone age. She hates me for it and curses her
> vendors at the same time now... There a
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.
(BTW, point-in-time recovery, a nice ex
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 mo
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
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
reprodu
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?).
Use a file based approach to managing your image data, and back up to
git. That way you can recover to any point. New files are put on the
file system and pushed into g
IMO:
Thanks for the comments Randy,
I'll follow up later on some of the details.
>
> “What approaches are people using with large Lidar datasets?”
>
> Beyond that I would like to see at least some lidar sets treated
> like the JPL srtm which is made accessible via WMS with pixel coded
> el
21, 2008 6:25 PM
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
Bruce,
I am not taking issue with database management of vector data sets,
but with the stuffing of raster data into databases. I still have not
heard a compelling use case for raster in the database.
12 million records is teensy. Stuff it into PostGIS. It's the billion-
point LIDAR sets t
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 momen
[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
day, February 21, 2008 6:25 PM
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.
Ind
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
20 matches
Mail list logo
