Le 23/02/2012 23:21, Martin Spott a écrit :
> when I
> can spend all the time on so many other enjoyable activities.
>
> Have fun,
> Martin.
Martin, I quote only this one, as I do know what can be felt in such
circumstances, and you're right, the most important: save time to enjoy
life.
What about building a wooden Tomcat sim in Torsten's garden ? Or rear
goats in south of France (good wine here, good network too).
Kindly,
Alexis

Am 24.02.12 21:44, schrieb Christian Schmitt:
> flightgear@... wrote:
>
>> [...] I really wish we
>> could build some kind of temporary "Scenery Team" and discuss ideas.
>> My proposal is to meet at IRC on day the next weeks to start
>> organizing, or to open a temporary group or list. (Sorry, i do not
>> like the forum for such).
>
> A "scenery team" is no bad idea and overdue. There ARE people who have
> proven in the past that they like to work on the scenery basics and not
> only create custom scenery. I had so many contributions to the CS DB,
> that I did not catch up with the work (and am in fact still missing
> some parts).
> Let me mention though that there IS a #fg_scenery channel on IRC (with
> nobody in it) and having a meeting to coordinate ideas and capacities
> surely is a good start.
>
> In the mid- to longterm perspective I'd like to make more advancements
> on the terragear side, to enable us to rebuild single tiles when there
> are changes. This is possible already, as many of you know, but then in
> most cases the newly created tile does no longer match fit to its
> neighbours, which results in gaps. If we could iron this out, we'd be a
> whole lot further down the road...
>
> Chris
>
Proposal for a first small meeting at #fg_scenery channel, this weekend:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=IRC+Meeting+%40+%23fg_scenery&iso=20120226T17&p1=945&ah=1
Cheers, Yves

flightgear@... wrote:
> [...] I really wish we
> could build some kind of temporary "Scenery Team" and discuss ideas.
> My proposal is to meet at IRC on day the next weeks to start
> organizing, or to open a temporary group or list. (Sorry, i do not
> like the forum for such).
A "scenery team" is no bad idea and overdue. There ARE people who have
proven in the past that they like to work on the scenery basics and not
only create custom scenery. I had so many contributions to the CS DB,
that I did not catch up with the work (and am in fact still missing
some parts).
Let me mention though that there IS a #fg_scenery channel on IRC (with
nobody in it) and having a meeting to coordinate ideas and capacities
surely is a good start.
In the mid- to longterm perspective I'd like to make more advancements
on the terragear side, to enable us to rebuild single tiles when there
are changes. This is possible already, as many of you know, but then in
most cases the newly created tile does no longer match fit to its
neighbours, which results in gaps. If we could iron this out, we'd be a
whole lot further down the road...
Chris

Am 24.02.12 16:25, schrieb Olivier:
> Hopefully, our form-based PHP scripts will hopefully avoid quite a lot of
> mistakes before uploading. However, I really think - I'm going to do it now,
> that this contribute.php page is not widely known enough. Goind to post it
> again on the newsletter and on the forums.
>
> Oliver
>
Just to mention once because I think some people don’t know about: I
share a small set of resources with official mapserver since some
months, I have a postgres/postgis server running here too. Of course it
is not that powerful like the whole mapserver network, it is not a
complete mirror, but it is enough to run some tests. This infrastructure
is dedicated to the mapserver and world scenery idea and was a base to
discuss some ideas with Martin and others.
If someone wants to run some tests (i.e. building webinterfaces etc.),
needs mirrored tables or whatelse, doors are open. (Martin and me are
sharing a small set of resources in the area of mapnik/navaids, maybe
you noted that already on the official mapserver.)
For me it was much easier to develop some new ideas for the mapserver in
this "private" test environment. And it stays open for other FlightGear
developers who want to run some tests. Recent apt.dat tables are
available (810 and 850). Scenery or object tables could be mirrored too,
if necessary (maybe I need to upgrade to postgresql 9 before).
That’s the free available foss resource I can share at the moment. I
need the server for my private mapnik geoserver tests, but I am open to
everyone who needs a small geoserver with all (more or less) recent
tools installed. Only restriction -> Target World Scenery Project.
Cheers, Yves

On Fri, Feb 24, 2012 at 8:00 AM, Thorsten Renk wrote:
> Not as such, but if the whole file structure gets redone, might we at this
> point consider making regional textures by xml conditionals easy in the
> new file structure?
>
> See here for the concept:
> http://www.flightgear.org/forums/viewtopic.php?f=5&t=12031&start=15
The work I'm doing should make this a bit easier, though I'm not changing
the file format itself.
> If we add something like this in now, we might also come to the point of
> implementing a re-parsing of materials.xml at runtime, so textures could
> switch on a transatlantic flight from US type to Europe type.
Certainly. I'm now familiar enough with the code that this should be fairly
straightforward to implement. I'll add it to my TODO list. There are already
a couple of conditional statements in materials[-dds].xml that really should be
evaluated at tile-load time rather than startup.
> Regional texturing is a feature which would be nice on GIT - by now, we
> also have enough GPL-compatible textures to pull it off (a while ago,
> Adrian posted a very impressive GLP texture pack in the forum).
>
> I'd be willing to help implementing it.
That would be great. I saw the textures on the forum, but haven't had the
chance to look at them. I suggest implementing this in a separate directory
(Materials/regional) once the new file structure is in place
(hopefully tonight).
On Fri, Feb 24, 2012 at 8:42 AM, Torsten Dreyer wrote:
> What about having a sub-subdirectory structure to avoid name mangeling, like
> Materials/base/ (contains all common files and includes)
> Materials/default/ (contains the default definitions and textures)
> Materials/dds/ (contains the dds definitions and textures)
Excellent idea. Will do!
I'm going to leave the existing materials[-dds],xml files unchanged for now
so people can easily go back to them if they find bugs in the new versions
of the files.
-Stuart

Hi Martin,
As Gijs and Thorsten Renk have mentioned, one issue is the lack of a
new world scenery build. At present, scenery developers have to build
and distribute their scenery creations themselves, and without any
information on how close we are to a new world scenery to be
distributed via TerraSync, I can imagine that they see little
motivation to submit their shapefiles to the DB. Obviously I don't
agree with that viewpoint!
Your announcement of having a Topologically clean dataset suggests
that we're getting significantly closer to being able to build the
entire world using new data such as CORINE and custom data sets. Could
you outline what work is still required, and how much effort it is
likely to require?
Doing so might encourage additional developers to step up,
particularly if it might be possible to have a scenery build to go
with 2.8.0.
Once we have the ability to create complete scenery builds with every
release, to be distributed via TerraSync, I think we'll see many more
scenery developers submitting to the DB.
-Stuart

Though I myself have an independent scenery project, I whole heartedly
support the global scenery project. Without it, and all your hard work
on it over the years, flightgear scenery would be a mere shadow of
what it is today. I hope then, after a break and some rest, that you
will regain your passion and motivation for the project and find a way
to continue on with it..even if in a reduced capacity.
I say give no thought to people creating external scenery. As far as I
have seen none of it was created out of spite towards the global
scenery database, nor do I recall any of its authors saying there
motivation for creating it was because they disagree with the global
scenery project or have any ill will towards it. In fact the only
reason I see that much of it exists is out of necessity..either due to
past license issues with data...or now as a temporary measure while we
wait for tools to stable up and a new global scenery generated with
that data. Of course there are a few oddball projects about where
people create 'exlusive' scenery objects or airports or
whatever...which I don't care for personally...but those are the
exception not the norm.
I doubt anyone would disagree that the global scenery is by far the
most important scenery project, without which fgfs scenery would be in
a much worse state. However I don't believe the official global
scenery project and independent scenery projects are mutually
exclusive. There is a time and place for both in my opinion.
best wishes..cheers

I just don't understand why these submissions are not just refused with a baked reply. You all are burning yourself and then will blame the community as a whole in anger.
Please enforce the rules !
Regards,
-Fred
Gijs de Rooy <gijsrooy@...> a écrit :
> Oliver wrote:
> Goind to post it again on the newsletter and on the forums.
Made it a "Forum announcement", so it shows up on top :)
Anyway, as RTFM (Read The FlightGear Manual) is clearly not the strongest part of our community,
I doubt it will help much. I've got exactly the same problem with the livery database: made a nice list
of criteria/rules, and what do I get? Packages without thumbnails, non-realistic liveries etc.
It's just the way it is I guess...

> Basically I see two different approaches in FlightGear Scenery world
> (aside from a few minor blends):
> 1.) Focus all ressources on one common World Scenery.
> 2.) Build pools of individual (and sometimes even contradicting)
> scenarios - also known as the M$FS way.
>
> It's obvious that 1.) was the one I tried to accomplish. I was
> convinced that, as a non-commercial OpenSource project, we could do
> "better". Anyhow it's obvious that 2.) draws magnitudes more developer
> ressource and the gap is steadily increasing. I've even watched people
> explicitly trying to persuade/convince contributors _not_ to contribute
> to common, collaborative Scenery ressources - and, what's really sad,
> not one single voice objected.
>
> That's why I consider my approach as a failure, maybe not generally,
> but at least in FlightGear land because apparently there's no critical
> mass of fertile soil to make it grow even half as fast as it could.
> For a long time I thought this would be a failure of "The FlightGear
> Community", but the more I think about it, the more I'm getting to the
> conclusion that there is simply no community in FlightGear Scenery
> land. Either there's a fundamental difference in the understanding of
> the term "community" - or 95 % of those who are repetitively exercising
> this term are just a crowd of narcissists ....
I guess as far as scenery goes, I certainly qualify as an outsider, so
here are my two cents. As far as my experience goes, this sums it up quite
nicely:
> Just for the record, that's one of the common, big, but most avoidable
> mistakes: "Submitting when it's finished".
Since my first contact with Flightgear a few years ago, I have never
witnessed that world scenery has grown more detailed. Objects - yes, but
for me personally landclass and elevation resolution matters much more.
Basically, during my whole Flightgear life, the world scenery has always
been what it is.
In my first year, I've occasionally asked when new world scenery will be
available. Afterwards, I've given up.
I was (and still am) glad that more and more custom scenery patches
appeared. It is very obvious to me that this approach has its limits,
there are errors and seams visible - but all in all, it enabled me to pick
the areas where I like to fly and enjoy that while waiting for the real
thing. Whenever that may happen.
I read many forum posts, I follow this list - and yet I have zero idea
what the status of the world scenery is, I couldn't even guess when, say,
Europe might be moved consistently to CORINE data, I have no idea what the
current issues in scenery development are.
And I had no idea about your frustration right until reading your post.
And I required your two follow-up posts to understand just what the issue
is.
Just maybe, there is a communication issue involved here (but let's also
allow for the possibility that I am just too dumb).
A community doesn't usually organize spontaneously in my experience - it
has also something to do with the flow of information and ideas, with
social skills (there are some people I enjoy interacting with, there are
others with which I can interact if necessary) and last a good bit of luck
to find the right person at the right time. Maybe, if there'd be a clear
perspective for contributions to world scenery to appear, developers would
be less likely to do their own patches of the planet. Maybe not.
Having said that, I would also very much like to thank you for the work
you have done. I don't understand enough of the details to fully
appreciate it, but I do know that it is crucial for all bits of scenery I
like. And I woul like to make it very clear that me being grateful for,
say, Pacific Northwest Scenery doesn't take away my appreciation for your
work.
> I really feel a strong manpower in FG on aircrafts, on shaders and
> weather items,
And I wonder where that feeling comes from, because despite trying to get
forum users interested in joining in weather-creation work (or texturing),
I have the feeling that this has basically failed. The situation I observe
is not really different from what Martin describes - the development of
the weather system rests on a few (at times seriously overworked)
individuals and there doesn't seem to be a pool of manpower to be tapped
if needed.
Being a theoretical physicist in real life, this is no different from
work, so I don't really mind that mode of development so much.
Best,
* Thorsten

Hi Martin,
I sent you yesterday some new scenery models to add and I haven't paid
attention to the emails on fg mailing list... For one year I'm working
as a scenery modeler, I didn't know all the problems you met, and I'm
deeply sorry for being so ignorant.
As a FG user, I really support the idea to have one main common scenery,
because it's more convenient thanks to Terrasync and I'm sure there are
a lot of people who think like this too. Flightgear is an open source
project and it's a good opportunity to do that.
Thank you so much for all your work and your contribution to Flightgear.
You deserve some rest and as Pedro said, I also hope one day to see you
come back, with new ideas.
I will also join the IRC discussion about that. I stopped using it a few
months ago but now, I think it's time to come back.
Thank you Martin!
Julien
Le 24/02/2012 16:03, Martin Spott a écrit :
> Gijs de Rooy wrote:
>
>> To give one recent example that applies to most of these reasons: LOWI. It has an updated airport layout, custom landclassing
>> and is under heavy development. The author told me that he'll put all of it in the database once it is finished.
> Just for the record, that's one of the common, big, but most avoidable
> mistakes: "Submitting when it's finished". I know, it's _really_
> common, but always carries the risk of making the same mistake with
> every of the included models.
> Guess how many hours I spent fixing the same stupid mistake in a row of
> models, mistakes which could have been avoided if people would have
> sent me each of these models _early_ !? Submitting early allows for
> early feedback and, as a consequence, for preventing avoidable mistakes
> early in the development phase of an airfield scenario, thus
> facilitating the rest of the submission process.
>
> I didn't track the number of hours, but, believe me, it kept me busy -
> and just for the stupid reason because people neither bothered reading
> our "Contribute" recommendations nor considered my advice.
>
> I know, Gijs, it's not your fault, I just hooked up because you
> mentioned.
>
> Cheers,
> Martin.

Hi Martin,
I sent you yesterday some new scenery models to add and I haven't paid
attention to the emails on fg mailing list... For one year I'm working
as a scenery modeler, I didn't know all the problems you met, and I'm
deeply sorry for being so ignorant.
As a FG user, I really support the idea to have one main common scenery,
because it's more convenient thanks to Terrasync and I'm sure there are
a lot of people who think like this too. Flightgear is an open source
project and it's a good opportunity to do that.
Thank you so much for all your work and your contribution to Flightgear.
You deserve some rest and as Pedro said, I also hope one day to see you
come back, with new ideas.
I will also join the IRC discussion about that. I stopped using it a few
months ago but now, I think it's time to come back.
Thank you Martin!
Julien
Le 24/02/2012 16:03, Martin Spott a écrit :
> Gijs de Rooy wrote:
>
>> To give one recent example that applies to most of these reasons: LOWI. It has an updated airport layout, custom landclassing
>> and is under heavy development. The author told me that he'll put all of it in the database once it is finished.
> Just for the record, that's one of the common, big, but most avoidable
> mistakes: "Submitting when it's finished". I know, it's _really_
> common, but always carries the risk of making the same mistake with
> every of the included models.
> Guess how many hours I spent fixing the same stupid mistake in a row of
> models, mistakes which could have been avoided if people would have
> sent me each of these models _early_ !? Submitting early allows for
> early feedback and, as a consequence, for preventing avoidable mistakes
> early in the development phase of an airfield scenario, thus
> facilitating the rest of the submission process.
>
> I didn't track the number of hours, but, believe me, it kept me busy -
> and just for the stupid reason because people neither bothered reading
> our "Contribute" recommendations nor considered my advice.
>
> I know, Gijs, it's not your fault, I just hooked up because you
> mentioned.
>
> Cheers,
> Martin.

> Oliver wrote:
> Goind to post it again on the newsletter and on the forums.
Made it a "Forum announcement", so it shows up on top :)
Anyway, as RTFM (Read The FlightGear Manual) is clearly not the strongest part of our community,
I doubt it will help much. I've got exactly the same problem with the livery database: made a nice list
of criteria/rules, and what do I get? Packages without thumbnails, non-realistic liveries etc.
It's just the way it is I guess...

________________________________
De : Martin Spott <Martin.Spott@...>
>I didn't track the number of hours, but, believe me, it kept me busy -
>and just for the stupid reason because people neither bothered reading
>our "Contribute" recommendations nor considered my advice.
Hopefully, our form-based PHP scripts will hopefully avoid quite a lot of
mistakes before uploading. However, I really think - I'm going to do it now,
that this contribute.php page is not widely known enough. Goind to post it
again on the newsletter and on the forums.
Oliver

Gijs de Rooy wrote:
> To give one recent example that applies to most of these reasons: LOWI. It has an updated airport layout, custom landclassing
> and is under heavy development. The author told me that he'll put all of it in the database once it is finished.
Just for the record, that's one of the common, big, but most avoidable
mistakes: "Submitting when it's finished". I know, it's _really_
common, but always carries the risk of making the same mistake with
every of the included models.
Guess how many hours I spent fixing the same stupid mistake in a row of
models, mistakes which could have been avoided if people would have
sent me each of these models _early_ !? Submitting early allows for
early feedback and, as a consequence, for preventing avoidable mistakes
early in the development phase of an airfield scenario, thus
facilitating the rest of the submission process.
I didn't track the number of hours, but, believe me, it kept me busy -
and just for the stupid reason because people neither bothered reading
our "Contribute" recommendations nor considered my advice.
I know, Gijs, it's not your fault, I just hooked up because you
mentioned.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Hi all, and especially Martin,
first of all let me say that I completely respect your decision. I'm sure, knowing you're way of decision making, that you've
been thinking it over for a while.
Without trying to change your opinion, I do like to give you my view on the scenery issue. You know that I support a centralized
scenery database, but through the extensive contact with "the community" (if I may say so) I did gain some respect for their
reasoning. More on that below.
Now that automated scenery downloading (via TerraSync) is integrated into the sim there are more scenery-database users
than ever. So it's importance is definitely not decreasing, even the contrary!
Talking to many (new) users and (scenery) developers over the past years I've found that there are reasons (you can argue
whether they are valid reasons, but they are reasons) for releasing scenery independant from the scenery database:
Landclassing: submitting landclassing data to the scenery database is rather easy. I did some parts myself
(West Frisian islands, Dubai, Manhattan). Two years after I submitted Dubai, it's still not included in the
scenery. If I'm not mistaken, the last scenery build dates back to 2008... I don't blame Martin for this (absolutely
not), it's just an observation.
Airport layouts: following up on the previous point, updates for airport layouts can be submitted. Another thing
I've done for quite some airports. But, since the terrain isn't rebuilt after such changes, airport layouts that were
updated years ago are still nothing more than a few lines in a .dat file.Object placement: various airports are/were so incorrect in the scenery (there's an airport in Belgium that's 300m
shifted IIRC) that it's impossible (and a waste of time) to place objects in such a way that they don't interfer with the
(bad) layout.Annoying the scenery maintainers: when you add a lot of objects, and are still updating them frequently, you
don't want to annoy the scenery maintainers with dozens of requests/updates. Oliver is tackling this part with the
automation.
Licensing: we don't have much scenery that's non-gpl, but there are a few areas. This is obviously a good reason
that we cannot do much about.
To give one recent example that applies to most of these reasons: LOWI. It has an updated airport layout, custom landclassing
and is under heavy development. The author told me that he'll put all of it in the database once it is finished. Altough I don't
know his exact reasoning, I imagine the above mentioned reasons are certainly part of it.
In order to tackle these reasons, we need to have more frequent scenery builds. If I'm not mistaken that is/was on Martin's
todo-list. After submitting an airport layout or shapefile update, scenery should get rebuilt automatically. I am aware of the
challenges with that (eg. gaps between tiles). I'd like to learn how I can help. Yves, I'll try to come on IRC the next week for
sure, excellent idea!
I'll stop writing now, already typed to many words for the current University project this morning. Getting dizzy from all the
words that passed my screen the last 6 hours or so...
Last but not least: Martin, thanks for all you've done! I'm sure there will be one day that the majority will be thankfull for
everything you did! In fact all TerraSync users already are (without knowing I assume).
Cheers,
Gijs

Am Freitag, den 24.02.2012, 09:41 +0000 schrieb Martin Spott:
> >From my perspective the really relevant paragraph in my posting is this
> one:
> Basically I see two different approaches in FlightGear Scenery world
> (aside from a few minor blends):
> 1.) Focus all ressources on one common World Scenery.
> 2.) Build pools of individual (and sometimes even contradicting)
> scenarios - also known as the M$FS way.
>
> It's obvious that 1.) was the one I tried to accomplish. I was
> convinced that, as a non-commercial OpenSource project, we could do
> "better". Anyhow it's obvious that 2.) draws magnitudes more developer
> ressource and the gap is steadily increasing. I've even watched people
> explicitly trying to persuade/convince contributors _not_ to contribute
> to common, collaborative Scenery ressources - and, what's really sad,
> not one single voice objected.
You're absolutly right.
In my opinion a key for success of 1.) is to NOT promote individual
scenery projects on the official FlightGear places.
So i suggest to remove all urls that do link to such individual scenery
projects from the FlightGear website, the wiki and even postings on the
flightgear forum.
Especially the latter might be very important.
If we make sure by force that individuals can't promote their own
scenery project on the forum or any other official place on FlightGear
they will have no laudation on their individual scenery projects.
This will nip individual scenery projects in the bud and will hopefully
lead to the way that such persons will freely submit their work to the
common World Scenery.
So 1.) can be ensured by force. Removing the urls is the key for that.
Forum moderators are able to do that.
As long as individual scenery projects can be promoted and guarantee
that way that such individuals will get attention for their one man show
2.) will stay attractive.
The key is to make 2.) unattractive by removing the promoting links to
those individual projects.
Best Regards,
Oliver C.

Hi Yves,
________________________________
De : "flightgear@..." <flightgear@...>
>I really wish we could build some kind of temporary "Scenery Team" and discuss ideas. My proposal is to meet at IRC on day the next weeks to start
>organizing, or to open a temporary group or list. (Sorry, i do not like the forum for such).
I completely second you on this, Yves, and I'm willing to help even with my small time & contributions. Don't know if IRC will be easy due to RL constraints, but will try to. At least we need to brainstorm ourselves a bit on a separate group or list to clearly:
1. Identify the people interested on this topic ;
2. Know where we are and what heading we want to take ;
3. Identify tasks : documentation, communication, technical aspects, etc.
>Personally- ... Martin, I would send you all my best wishes and I would send you one billion "Thank You"s for all your support. Without you I would never have
>seen what is behind the whole scenery process. You spent so much time explaining me how this all works, you shared your experience and all the results of your
> researches in idealistic way and you guided me through the jungle. You always studied all proposals carefully. I ever got an answer from you. All my respect.
Seconded++ too !
Olivier

Jörg Emmerich wrote:
> Did you notice that most products you buy today, do not have a real
> "User-Manual" any more - but tell you an Internet-Address to look it up?
Yup, that's really bad style and I still haven't given up the hope that
FlightGear is capable of doing better. Who knows ....
Guess why O'Reilly is selling so many books despite the fact that
there's plenty of online documentation on almost every topic they cover
- with probably the sole exception being their animal short reference, I
assume ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Hi all, Martin,
________________________________
> On Thu, Feb 23, 2012 at 10:21 PM, Martin Spott <Martin.Spott@...>wrote:
>
> In the mid of the last decade I've been one of those who realized that
> developing a long-term strategy for the various FlightGear Scenery
> ressources would be a Really Good Idea.
In fact, in my opinion, the real big strength of FG over other sims (apart the fact its
free & opensource) is its capacity to be pulled/pushed centrally, either by Git or through
central databases. Our architecture enables us to avoid having hundreds of scenery
or aircraft sites everywhere, with multiple patches and software to download and
update - those of you who have been using other sims know what I'm talking about.
This is a real strength. Let's not make it a weakness.
Because, I feel - just like Martin - there are more and more "political" posts showing
that everyone does not feel the same. Maybe a language barrier - maybe something
not understood about this or the way the FG project "works", sometimes sad licensing
or human issues.
The scenery generation part of FG, which is mostly unknown of many of us,
deserves a proper attention - I recently began to understand a small part of the way
it works, and it's a highly complicated, still so important part of FG.
Maybe we need to make more talks about it, to talk about the way it works in the
Wiki or in the newsletter or here, but this takes a lot of time too.
Everyone wants to have a better scenery in FG. However, it's not possible on such
a big project as FG, to leave the responsability - and maintenance - and evolution -
and validation - of such critical parts of FG to just one or two persons. Not good for
them, not good for the project. And it's also true that most of this work is not known
or even noticed. Meanwhile, it's easy to complain and say "we deserve better scenery".
Martin - I'm talking for me but for many also - be sure the work you've done and
you're doing has a real sense.
You are getting overloaded by submissions, and you just can't be working on the
scenery validation, the scenery generation, and the work on the tools themselves.
To reduce the overload you encounter, I've been working on webtools to try to make
submission, edition, deletion of scenery objects easier. There is still some work there,
and I hope to have all of them finished by the end of the summer.
To reduce this load even more, I would suggest:
- to start thinking of having regional maintainers - 1 per continent, for now, managing
scenery submissions, while someone keeps monitoring the whole process;
- to have one or two more people interested in GIS and able to second you on maintaining
and upgrading the scenery generation process;
- to continue the work on the scenery web tools to reduce this unbearable human load.
I really feel a strong manpower in FG on aircrafts, on shaders and weather items, sometimes
relying on individuals or on teams, meanwhile the scenery "backoffice" really lacks more
talented people like you.
Olivier

I really hope that we can start a discussion now about the state of
the scenery and making (or following) some plans keeping the basic
ideas up for the moment, also looking to planned improvements. I am
following Martins ideas since a long time. I always tried to help here
and there but I saw that it really needs a lot of people following
this ideas. Martin spent so much time explaining me how to set up this
and that and how all this scenery process could work. I really wish we
could build some kind of temporary "Scenery Team" and discuss ideas.
My proposal is to meet at IRC on day the next weeks to start
organizing, or to open a temporary group or list. (Sorry, i do not
like the forum for such).
Personally- ... Martin, I would send you all my best wishes and I
would send you one billion "Thank You"s for all your support. Without
you I would never have seen what is behind the whole scenery process.
You spent so much time explaining me how this all works, you shared
your experience and all the results of your researches in idealistic
way and you guided me through the jungle. You always studied all
proposals carefully. I ever got an answer from you. All my respect.
Cheers, Yves
----- Ursprüngliche Nachricht --- Von: "FlightGear developers
discussions" @lists.sourceforge.net>
An:
Cc:
Gesendet:Fri, 24 Feb 2012 10:01:16 +0000 (UTC)
Betreff:Re: [Flightgear-devel] Looking at a nice project from outside
Pedro Morgan wrote:
> On Thu, Feb 23, 2012 at 10:21 PM, Martin Spott wrote:
>
>> In the mid of the last decade I've been one of those who realized
that
>> developing a long-term strategy for the various FlightGear Scenery
>> ressources would be a Really Good Idea. Meanwhile there's been
>> progress to make such a strategy happen, anyhow, as usual, the
>> groundwork doesn't have much of a shiny surface, it doesn't have
>> eye-candy.
>>
>
> Martin, am right with you.. I understand.. its a php site.. and its
on a
> server and your dont want it to go wrong..
Pedro, the ground work I'm talking about is not the visible web site,
it's the infrastructure behind these web pages: Man-months of
research
and tests in GIS land, building and testing tools, building and
maintaining the database, shaping all the data into its current form
and loading it into the DB, researching and testing how to build
detailed airport layouts with TerraGear, the same with OSM roads,
ensuring a certain quality level for the land cover data as well as
for
the Scenemodels repository .... and so on.
Just to mention one symptomatical example: It's really weird doing a
lot of research and tests, investigating licenses, compatibility
issues
and the like - and to realize months or years later that others, who
don't care at all about these implications, are gaining laurels.
After you've gone through this sort of a story more than twice, then
you're finally going to ask yourself if there's any sense in what
you're trying to achieve.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
are !
--------------------------------------------------------------------------
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@...
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
.spott@...>@lists.sourceforge.net>

I was surprised that this shift in Paradigms has such a big handicap to
be considered for future developments. And if you believe you are
"old-fashioned", how about a 70 year old guy that started in Computer
Development in 1970, and whose big boss predicted: "I think there is a
world market for maybe five computers." (Thomas Watson, president of
IBM, 1943!) You may have some more laughs on
http://www.pcworld.com/article/155984/the_7_worst_tech_predictions_of_all_time.html).
Thus let me comment on the most controversial replies out of my sight:
I admit: Also I still read my Newspaper in hardcopy during breakfast -
but for more details I follow the advise (or QR-code) inside the daily
Newspapers or TV-news to look up details on their homepage. And surely a
professional designer must study lots of hardcopy books (and pay lots of
money for those!) - but I do not believe that nowadays any PC-USER of a
"hobby-product" (may he be high or low skilled) will go to a Public- or
University-Library for details! (Remember: We talk about a "getstart for
a hobby" - not a "Masters-Degree in...").
And I am pretty sure that not many users of FlightGear print the
"getstart.pdf" - and they will do so even less in the future! And even
if it gets printed, it is printed on standard PC-Printers! Or can I buy
that book anywhere with a superior Print-Quality? And do I get a printed
update for new versions? (Now every 6 month?)
Did you notice that most products you buy today, do not have a real
"User-Manual" any more - but tell you an Internet-Address to look it up?
(A modern way to avoid the law to provide those manuals in the national
language!)
Anyhow: Did you ever try e.g. (with Firefox 10.0.2)
"http://wiki.flightgear.org/Howto:_Using_QGIS_and_satellite_pictures";:
--> mouse-click "File" --> "Print" (or "Print Review") and compare that
to the "getstart.pdf"? Do you see a significant difference in
printing/reading quality?
I would support the need for an "authoritative raw source" - if there is
the manpower to maintain it! - over decades? It surely would be a good
reference for all upcoming versions.
I admit: Page-Referencing (and especially the old style Indexing) is a
problem for HTML -- if reading hardcopy! In the reverse it is impossible
to reference between multiple PDF-documents to unique text-positions! So
neither approach is the "Golden Egg" in a mixed environment. I tried to
compromise for that with: Smaller "books" (so headers are enough - no
real need for page-numbers).
The amount of cross-referencing may have some negative side effects,
when reading top to bottom and jumping to each and every reference - but
surely it is extremely positive having the possibility to jump to more
details (when wanted/needed) and directly return to the place you were
-- all of that with two mouse-clicks instead of wetting your fingers and
search through lots of paper-pages!).
In addition those smaller books with a lot of referencing ensure that
each subject needs to be described only in one chapter - thus changes
have to be "updated" only once - and not in several books and/or
chapters.
Especially the aspect of controlling changes promotes the use of WIKI,
because whoever is concerned can set a mark to be notified about any
changes made by anybody - and can delete or correct changes made -- see
the history options in the FGFS-wiki. So you may have lots of observers!
To the end: I was surprised not seeing any comments to the problem of
"multi-lingual" support - which was the starting point for this
controversial work of mine. I am sure nobody explicitly wants to
restrict FlightGear just to people being able to read and write English.
But I guess this point is an unsolved question for todays
"getstart.pdf". So I guess there is no problem if I just input my German
version into the FGFS-WIKI - not as an "authoritative raw source" - but
hoping it may help some other "Tongues" for their translations.
joe

Pedro Morgan wrote:
> On Thu, Feb 23, 2012 at 10:21 PM, Martin Spott <Martin.Spott@...>wrote:
>
>> In the mid of the last decade I've been one of those who realized that
>> developing a long-term strategy for the various FlightGear Scenery
>> ressources would be a Really Good Idea. Meanwhile there's been
>> progress to make such a strategy happen, anyhow, as usual, the
>> groundwork doesn't have much of a shiny surface, it doesn't have
>> eye-candy.
>>
>
> Martin, am right with you.. I understand.. its a php site.. and its on a
> server and your dont want it to go wrong..
Pedro, the ground work I'm talking about is not the visible web site,
it's the infrastructure behind these web pages: Man-months of research
and tests in GIS land, building and testing tools, building and
maintaining the database, shaping all the data into its current form
and loading it into the DB, researching and testing how to build
detailed airport layouts with TerraGear, the same with OSM roads,
ensuring a certain quality level for the land cover data as well as for
the Scenemodels repository .... and so on.
Just to mention one symptomatical example: It's really weird doing a
lot of research and tests, investigating licenses, compatibility issues
and the like - and to realize months or years later that others, who
don't care at all about these implications, are gaining laurels.
After you've gone through this sort of a story more than twice, then
you're finally going to ask yourself if there's any sense in what
you're trying to achieve.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

>From my perspective the really relevant paragraph in my posting is this
one:
Martin Spott wrote:
> The idea I had in mind, the motivation which drove me into dedicating
> so many hours was to focus as many of the available ressources as
> possible on building the best _common_ Scenery we could make for
> FlightGear.
> Yet I have to realize that this idea has become pretty unpopular. The
> sort of collaboration which is being carried out at improving
> FlightGear's source code and the sense for continuous development
> obviously don't work in the Scenery department.
Basically I see two different approaches in FlightGear Scenery world
(aside from a few minor blends):
1.) Focus all ressources on one common World Scenery.
2.) Build pools of individual (and sometimes even contradicting)
scenarios - also known as the M$FS way.
It's obvious that 1.) was the one I tried to accomplish. I was
convinced that, as a non-commercial OpenSource project, we could do
"better". Anyhow it's obvious that 2.) draws magnitudes more developer
ressource and the gap is steadily increasing. I've even watched people
explicitly trying to persuade/convince contributors _not_ to contribute
to common, collaborative Scenery ressources - and, what's really sad,
not one single voice objected.
That's why I consider my approach as a failure, maybe not generally,
but at least in FlightGear land because apparently there's no critical
mass of fertile soil to make it grow even half as fast as it could.
For a long time I thought this would be a failure of "The FlightGear
Community", but the more I think about it, the more I'm getting to the
conclusion that there is simply no community in FlightGear Scenery
land. Either there's a fundamental difference in the understanding of
the term "community" - or 95 % of those who are repetitively exercising
this term are just a crowd of narcissists ....
Actually I doubt wether a continuation of my approach makes sense in
the context of The FlightGear Project. At least I see no point in
further working on 1.) whereas 2.) is getting by magnitudes more
appraisal and, what is most important, support. If I were convinced
there's a light at the end of the tunnel, then I would certainly
continue instead of giving up, but under the current conditions I
don't.
This is the actual reason for my decision, not the lack of time (people
who know me have already familiarized with the fact that I'm
notoriously running out of time, thus there's nothing special now).
In the long term I'll probably leave the entire project because I
basically haven't done anything else than Scenery infrastructure over
the past years. Trying to write and coordinate documentation wasn't
much of a success story either .... but that's a different topic.
Ah, btw, indeed two recent incidents convinced me to make this decision
now, but they were having no effect on the decision itself, just on the
particular timing.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------