"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Going a slightly different direction with this, the latest scenery
> build consumes almost 7Gb (up from the previous 4.5Gb) which means it
> takes me about 11 cd's to fully contain it.
Is the new rebuild already complete ? I'm wondering:
bash-2.03$
Martin Spott writes:
> I would not use highly detailed scenery as a default. I'm thinking of a
> scenery database as a repository which serves as a data source for the
> usual terrain build process (not to serve as the run-time scenery
> itself!). So if people are really interested in using highres
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> And I am worried about security issues when we have thousands of
> users all wanting to update their little piece of the earth :-)
I didn't mean that _everyone_ should be able to write to the "scenery
database" (or however we'd call it _if_ it really sho
Martin Spott writes:
>
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
> > Martin Spott writes:
>
> >> We would need a database where everyone around the world could be
> >> granted write access to a dataset that is kept at one central point
> >> (later we might talk about replication or a distribute
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> Martin Spott writes:
>> We would need a database where everyone around the world could be
>> granted write access to a dataset that is kept at one central point
>> (later we might talk about replication or a distributed database),
> I think we want to s
Martin Spott writes:
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
> > Martin Spott writes:
> >>
> >> I wonder how long it takes until someone imports the world's SRTM data
> >> into GRASS (with a networked database backend like PostGIS).
> >
> > AFAIK lots of people are doing this
>
> Do you sugg
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> Martin Spott writes:
>>
>> I wonder how long it takes until someone imports the world's SRTM data
>> into GRASS (with a networked database backend like PostGIS).
>
> AFAIK lots of people are doing this
Do you suggest we should do so too ? Why don't peop
Martin Spott writes:
>
> I wonder how long it takes until someone imports the world's SRTM data
> into GRASS (with a networked database backend like PostGIS).
AFAIK lots of people are doing this
> I assume
> quite a few people not related to FlightGear already have data that
> could be merged. T
David Megginson <[EMAIL PROTECTED]> wrote:
> Norm is right that the only robust solution is to build a big, central
> database-driven GIS repository, where we can check out individual
> polygons, lines, and elevation points, edit them, and then check them
> back in again (preferably in a distribut
Martin Spott writes:
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
> > Martin Spott writes:
> >> "Norman Vine" <[EMAIL PROTECTED]> wrote:
> >>
> >> > This can be turned into a Polygon Algebra abstraction,
> >>
> >> Every piece of manually
> >> refined land cover or terrain elevation could be tagge
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> Martin Spott writes:
>> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>>
>> > This can be turned into a Polygon Algebra abstraction,
>>
>> Every piece of manually
>> refined land cover or terrain elevation could be tagged with a
>> surrounding polygon.
> S
Martin Spott writes:
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>
> > This can be turned into a Polygon Algebra abstraction,
>
> Every piece of manually
> refined land cover or terrain elevation could be tagged with a
> surrounding polygon.
Sure sounds like "polygon algebra" to me :-)
see
htt
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> Martin Spott writes:
>> Oh, we _do_ have the ability to produce higer res data by hand. The
>> missing bit is a mechanism to modify the automatic scenery build so
>> that we can specify an order of different data sources to query.
>> This way we could hav
Martin Spott writes:
>
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>
> > There is no shortcut to be found here, spend your energies looking for
> > higher res data sets to splice in to the vmap0 locally !
>
> Oh, we _do_ have the ability to produce higer res data by hand. The
> missing bit is a
Martin Spott wrote:
"Norman Vine" <[EMAIL PROTECTED]> wrote:
There is no shortcut to be found here, spend your energies looking for
higher res data sets to splice in to the vmap0 locally !
Oh, we _do_ have the ability to produce higer res data by hand. The
missing bit is a mechanism to modify
"Norman Vine" <[EMAIL PROTECTED]> wrote:
> There is no shortcut to be found here, spend your energies looking for
> higher res data sets to splice in to the vmap0 locally !
Oh, we _do_ have the ability to produce higer res data by hand. The
missing bit is a mechanism to modify the automatic scen
Erik Hofman writes:
> Martin Spott wrote:
> > Erik Hofman wrote:
> >
> >
> >>I was wondering, since we have a global developers base, how difficult
> >>would it be to measure the error of the VMap0 data globally [...]
> >
> > You mean to take kown places for reference and determine the error of
Martin Spott wrote:
Erik Hofman wrote:
I was wondering, since we have a global developers base, how difficult
would it be to measure the error of the VMap0 data globally [...]
You mean to take kown places for reference and determine the error of
their placement in VMap0 data ? We'll have only a
Erik Hofman <[EMAIL PROTECTED]> wrote:
> I was wondering, since we have a global developers base, how difficult
> would it be to measure the error of the VMap0 data globally [...]
You mean to take kown places for reference and determine the error of
their placement in VMap0 data ? We'll have on
19 matches
Mail list logo
