Re: [Flightgear-devel] Sound problem stops FG start
Hi Lee > > On Friday 21 March 2008 01:07, Innis Cunningham wrote: >> Hi Lee >> >> DETAILS WERE HERE >> >>> On Thursday 20 March 2008 13:29, Innis Cunningham wrote: Hi Lee > Hi Innis, > > first of all, I just noticed that your replies are including > e-mail addresses - if they're not obfuscated in the mailing > list archives they'll be harvested for spam. Could you check > your e-mailer settings to make sure they're not included in > the body of the posting? I am not sure what you mean I use hotmail what are you seeing that I should look into. >>> >>> That's odd. This one has come through without the e-mail >>> addresses in the body. Have a look at your copies of this >>> thread and check your sent folder to see if you can see them in >>> your first reply to me, posted at 15:15 on 2008-03-19, then >>> re-quoted in my reply back to you at 15:35 on 2008-03-19. Then >>> finally, it's all quoted again when you replied at 01:41 on >>> 2008-03-20. >>> >>> Strange, but there's a reason for it somewhere. Hasn't >>> happened this time, so it's more of a curiosity than a problem. >> >> Ok I think I know what you are talking about there should be >> nothing at the top of the email were I put "details were here".I >> have always stripped that information off when I reply but this >> time I was just lazy is it supposed to be stripped off >> automaticly.I will keep that in mind in future > > Glad we got that clarified:) Stripping the info out, or only > including the body text, is usually the normal behaviour for e-mail > clients and I'd expect web-mail clients to do the same. Perhaps > there's a setting somewhere in your Hotmail settings, or perhaps it > just doesn't work properly - wouldn't be the first time that a bug > has appeared in a bit of software:) >> > Re the sound problem - If you get an identical error, > referring to exactly the same file, after removing the mkviii > folder it implies to me that the mkviii relies upon code > that's been built into FG and it's been done in such a way > that it means that the FG code consequently requires the > mkviii folder to run, even if it's not used. I have got my sound working now so I can hear the sounds as well as see them playing but still FG bails out with the same error. As this was a Ubuntu package that I installed I would have though it would have worked.But does OpenAL need a 64 bit version to work with a 64bit CPU.As I say I do not have this problem running this same package on a 32bit machine > Therefore, you've got to fix your OpenAL, which is what Eric > said. > > LeeE Thanks again for your help and let me know about the email problem as I am no guru in this area. Cheers Innis >>> >>> Heh:) - I'm no guru either. Did you fix the sound by >>> installing new/updated OpenAL packages? If so, have you >>> re-compiled everything to pick up the new packages? >> >> No the onboard sound I have is usb audio(new to me)I had to >> change some Ubuntu settings to make it work.As far as I can >> tell I have the correct OpenAL package for the 32bit version of >> of Ubuntu 7.10(gutsy)I am running.I guess I would have to >> force install or build from source to use a different package. >> I guess FG wont run if it does not OpenAL >> >>> LeeE >> >> Cheers >> Innis > > I'm a bit at a loss for further suggestions - if OpenAL is working > ok with your other apps there's no reason why it shouldn't work > with FG. The actual audio device shouldn't make any difference > because that sits on the other side of OpenAL and FG shouldn't be > trying to talk to the sound hardware directly. Well everything seems to be working now but the upshot of it is I dont know exactly why.I used the asound command on the command line to reset my audio device and sometime after that it all worked. Murphy's law kicked in I was just finishing a long post to the Ubuntu forum and I needed to quote the exact error I was getting so I booted FG from the CLI and the next thing I know I am sitting at KSFO.Go figure. Anyway Thank you very much for your help with this. Now all Ineed is to get my two computers to talk to one another on the NFS. They talk to the Bxxxdy widows computer but not to one another. I think my linux computers have a serious communications problem.:-) > > LeeE Cheers Innis _ Search for local singles online @ Lavalife http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
LeeE wrote: > So it looks like we either live with the problem until someone else > creates a new database with all the problems fixed, or bite the > bullet and fix it manually ourselves. Yep, that's the spirit ;-) > Would it be possible to cobble together a small utility that would > allow small parcels of the scenery database e.g. 1x1 deg tiles, to > be checked and corrected manually without setting up the full > scenery build system? That way, many people could work on it > whenever they feel like it. I've had to do this sort of manual > data correlation/verification a couple of times over the years, on > different projects I've worked on, and while it sounds like an > onerous and tedious task it's not too bad if you can just do bits > of it, now and then, as a break from your primary tasks. You could use qgis or any other GIS for that. No need to work on scenery files and no need for firing up the scenery generation system at all. It would still be possible to allocate the tasks in 1x1 deg tile portions. Still someone would have to implement that logic in a convenient way for editors to use. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
LeeE writes: > > Would it be possible to cobble together a small utility that would > allow small parcels of the scenery database e.g. 1x1 deg tiles, to > be checked and corrected manually without setting up the full > scenery build system? That way, many people could work on it > whenever they feel like it. I've had to do this sort of manual > data correlation/verification a couple of times over the years, on > different projects I've worked on, and while it sounds like an > onerous and tedious task it's not too bad if you can just do bits > of it, now and then, as a break from your primary tasks. > > Obviously, it would be a slow and long-term undertaking but at least > the problem would be fixed eventually, whereas the alternative > seems to be that it never gets fixed and we just have to live with > it. A little birdie told me that the OSM project is about doing just this :-) http://wiki.openstreetmap.org/index.php/Main_Page Note that the same services that host mapserver.flightgear.org and were used to build the latest fgfs scenery, host the development database of OSM Cheers Norman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
On Friday 21 March 2008 17:13, Curtis Olson wrote: > On Fri, Mar 21, 2008 at 12:07 PM, Ralf Gerlich wrote: > > AnMaster wrote: > > > Good question, I guess combining them and manually fixing the > > > problems > > > > would be too much > > > > > work. I got no really good solution. But the current > > > coastlines are very > > > > bad in many cases. > > > > > What about only using GHSSH for those coastlines around > > > continents? With > > > > that I mean coast > > > > > line around, say, North and south America, > > > Europe/Africa/Asia (that, > > > > apart from the Suez > > > > > channel, are connected), Australia and any islands, and > > > simply discard > > > > any coastlines > > > > > inside these "blocks" and use vmap0 there. That is: don't > > > trust how > > > > vmap0/GHSSH classify > > > > > the data. Would that be feasible? > > > > Feasible, as GSHHS explicitly makes the outer coastlines > > available and differentiates them from inner shorelines, but it > > wouldn't solve the problems with inconsistent waterways at the > > coastlines of continents. > > > > Even though that is a lot of work, manually adapting our > > VMAP0-based data to the GSHHS-data is the only solution I > > currently see. > > Right, this is basically what we did for 0.9.8 and ended up with > a bazillion inconsistancies ... > > Areas marked as lake/river in GSHHS but ocean in vmap0 will be > entirely skipped. > Areas marked as ocean in GSHHS and lake/river in vmap0 will be > doubled up and overlapped. > VMAP0 rivers may run short of the GSHHS coastline. > etc. > > There's no combination of these two datasets you can do perfectly > with an automated system. You would need a tremendous amount of > effort to visually inspect the entire data set and resolve any > problems manually. > > Regards, > > Curt. So it looks like we either live with the problem until someone else creates a new database with all the problems fixed, or bite the bullet and fix it manually ourselves. Would it be possible to cobble together a small utility that would allow small parcels of the scenery database e.g. 1x1 deg tiles, to be checked and corrected manually without setting up the full scenery build system? That way, many people could work on it whenever they feel like it. I've had to do this sort of manual data correlation/verification a couple of times over the years, on different projects I've worked on, and while it sounds like an onerous and tedious task it's not too bad if you can just do bits of it, now and then, as a break from your primary tasks. Obviously, it would be a slow and long-term undertaking but at least the problem would be fixed eventually, whereas the alternative seems to be that it never gets fixed and we just have to live with it. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound problem stops FG start
On Friday 21 March 2008 01:07, Innis Cunningham wrote: > Hi Lee > > DETAILS WERE HERE > > > On Thursday 20 March 2008 13:29, Innis Cunningham wrote: > >> Hi Lee > >> > >>> Hi Innis, > >>> > >>> first of all, I just noticed that your replies are including > >>> e-mail addresses - if they're not obfuscated in the mailing > >>> list archives they'll be harvested for spam. Could you check > >>> your e-mailer settings to make sure they're not included in > >>> the body of the posting? > >> > >> I am not sure what you mean I use hotmail what are you seeing > >> that I should look into. > > > > That's odd. This one has come through without the e-mail > > addresses in the body. Have a look at your copies of this > > thread and check your sent folder to see if you can see them in > > your first reply to me, posted at 15:15 on 2008-03-19, then > > re-quoted in my reply back to you at 15:35 on 2008-03-19. Then > > finally, it's all quoted again when you replied at 01:41 on > > 2008-03-20. > > > > Strange, but there's a reason for it somewhere. Hasn't > > happened this time, so it's more of a curiosity than a problem. > > Ok I think I know what you are talking about there should be > nothing at the top of the email were I put "details were here".I > have always stripped that information off when I reply but this > time I was just lazy is it supposed to be stripped off > automaticly.I will keep that in mind in future Glad we got that clarified:) Stripping the info out, or only including the body text, is usually the normal behaviour for e-mail clients and I'd expect web-mail clients to do the same. Perhaps there's a setting somewhere in your Hotmail settings, or perhaps it just doesn't work properly - wouldn't be the first time that a bug has appeared in a bit of software:) > > >>> Re the sound problem - If you get an identical error, > >>> referring to exactly the same file, after removing the mkviii > >>> folder it implies to me that the mkviii relies upon code > >>> that's been built into FG and it's been done in such a way > >>> that it means that the FG code consequently requires the > >>> mkviii folder to run, even if it's not used. > >> > >> I have got my sound working now so I can hear the sounds as > >> well as see them playing but still FG bails out with the same > >> error. As this was a Ubuntu package that I installed I would > >> have though it would have worked.But does OpenAL need a 64 bit > >> version to work with a 64bit CPU.As I say I do not have this > >> problem running this same package on a 32bit machine > >> > >>> Therefore, you've got to fix your OpenAL, which is what Eric > >>> said. > >>> > >>> LeeE > >> > >> Thanks again for your help and let me know about the email > >> problem as I am no guru in this area. > >> > >> Cheers > >> Innis > > > > Heh:) - I'm no guru either. Did you fix the sound by > > installing new/updated OpenAL packages? If so, have you > > re-compiled everything to pick up the new packages? > > No the onboard sound I have is usb audio(new to me)I had to > change some Ubuntu settings to make it work.As far as I can > tell I have the correct OpenAL package for the 32bit version of > of Ubuntu 7.10(gutsy)I am running.I guess I would have to > force install or build from source to use a different package. > I guess FG wont run if it does not OpenAL > > > LeeE > > Cheers > Innis I'm a bit at a loss for further suggestions - if OpenAL is working ok with your other apps there's no reason why it shouldn't work with FG. The actual audio device shouldn't make any difference because that sits on the other side of OpenAL and FG shouldn't be trying to talk to the sound hardware directly. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
On Fri, Mar 21, 2008 at 12:07 PM, Ralf Gerlich wrote: > AnMaster wrote: > > Good question, I guess combining them and manually fixing the problems > would be too much > > work. I got no really good solution. But the current coastlines are very > bad in many cases. > > > > What about only using GHSSH for those coastlines around continents? With > that I mean coast > > line around, say, North and south America, Europe/Africa/Asia (that, > apart from the Suez > > channel, are connected), Australia and any islands, and simply discard > any coastlines > > inside these "blocks" and use vmap0 there. That is: don't trust how > vmap0/GHSSH classify > > the data. Would that be feasible? > > Feasible, as GSHHS explicitly makes the outer coastlines available and > differentiates them from inner shorelines, but it wouldn't solve the > problems with inconsistent waterways at the coastlines of continents. > > Even though that is a lot of work, manually adapting our VMAP0-based > data to the GSHHS-data is the only solution I currently see. Right, this is basically what we did for 0.9.8 and ended up with a bazillion inconsistancies ... Areas marked as lake/river in GSHHS but ocean in vmap0 will be entirely skipped. Areas marked as ocean in GSHHS and lake/river in vmap0 will be doubled up and overlapped. VMAP0 rivers may run short of the GSHHS coastline. etc. There's no combination of these two datasets you can do perfectly with an automated system. You would need a tremendous amount of effort to visually inspect the entire data set and resolve any problems manually. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
AnMaster wrote: > Good question, I guess combining them and manually fixing the problems would > be too much > work. I got no really good solution. But the current coastlines are very bad > in many cases. > > What about only using GHSSH for those coastlines around continents? With that > I mean coast > line around, say, North and south America, Europe/Africa/Asia (that, apart > from the Suez > channel, are connected), Australia and any islands, and simply discard any > coastlines > inside these "blocks" and use vmap0 there. That is: don't trust how > vmap0/GHSSH classify > the data. Would that be feasible? Feasible, as GSHHS explicitly makes the outer coastlines available and differentiates them from inner shorelines, but it wouldn't solve the problems with inconsistent waterways at the coastlines of continents. Even though that is a lot of work, manually adapting our VMAP0-based data to the GSHHS-data is the only solution I currently see. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: | On Fri, Mar 21, 2008 at 11:00 AM, AnMaster wrote: | |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA512 |> |> It does indeed look like 0.9.8 had best coast line. Why is it so much |> worse in more recent |> scenery? Wouldn't it be possible to get the same good coastline as in |> 0.9.8? | | | As with anything, it's not quite that simple. The GHSSH coastline database | (used in 0.9.8) is indeed more accurate for ocean coastlines. However, for | any inland fresh water, it is much worse/less detailed than vmap0. So in | 0.9.8 we used GHSSH for coastlines and VMAP0 for lakes & rivers. | | However, we found that there were major discrepancies between the two | databases. For instance, lake washington near seattle is classified as lake | by GHSSH and ocean by vmap0, so it simply did not appear in 0.9.8. | Similarly there were things that were classified as ocean by GHSSH and lake | by vmap0 so they were both drawn on top of each other. | | The decision was made to go with vmap0 entirely. We gave up accuracy around | the coast lines, but we gained a much more consistent picture of the world | ... with no major missing bits and no overlapping sections. | | Originally we only used GHSSH defined waterways, but this let to major | problems, like the great lakes only being half defined (i.e. the canadian | side of the lakes was not mapped so there was only land there.) And | strangely, some Canadian's complained about that! :-) So we went to the | mixed GHSSH-Ocean/VMAP0-fresh-water scheme, but people complained about the | missing water that fell in the gaps between both dataset classifications. | So then we went to vmap0, but now people are complaining about less detailed | coast lines! | | What combination should we try next? :-) Good question, I guess combining them and manually fixing the problems would be too much work. I got no really good solution. But the current coastlines are very bad in many cases. What about only using GHSSH for those coastlines around continents? With that I mean coast line around, say, North and south America, Europe/Africa/Asia (that, apart from the Suez channel, are connected), Australia and any islands, and simply discard any coastlines inside these "blocks" and use vmap0 there. That is: don't trust how vmap0/GHSSH classify the data. Would that be feasible? Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH4+bmWmK6ng/aMNkRCrPAAJ9cnNn819/rhieMAOLM/aRP/VXc4QCgkHPA dW6e+qXIMwMmKnKKZoShDJE= =wyoA -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
One thing to add... Ralf Gerlich wrote: > Currently there is no shapefile version of GSHHS 1.5, which was > available for 1.3, so we need to get some tool to import the custom > binary format of GSHHS into the database, including the handling of > shorelines crossing the dateline, etc (e.g. Eurasia continent definition). > > Yes, this is on my TODO-list, and no, it's not on top. ...volunteers welcome ;-) The goal is to have something like a generic gshhs2ogr-converter that can convert gshhs to any format supported by the OGR library and outputs the data properly clipped to -180<=lon<=180, -90<=lat<=90. A tool independent of TerraGear but possibly using gpc would be favoured. One of the OGR-supported formats is PostgreSQL, which is the database software we are using on mapserver.flightgear.org. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi Curt! Curtis Olson wrote: > The decision was made to go with vmap0 entirely. We gave up accuracy > around the coast lines, but we gained a much more consistent picture of > the world ... with no major missing bits and no overlapping sections. Thanks for jumping in with that explanation. Anybody interested in details is invited to look at the data available on mapserver.flightgear.org. The database includes both the VMAP0 data and the GSHHS data. You may notice that at some points VMAP0 waterways supposed to flow into the ocean or a lake do not reach the shore as defined by GSHHS. I can imagine the disappointed comments coming up with if we used that set with the next scenery build... ;-) The database gives us the possibility to adjust these points, but it will be a whole lot of work and we first want to get the most current version of GSHHS into the database. Currently there is no shapefile version of GSHHS 1.5, which was available for 1.3, so we need to get some tool to import the custom binary format of GSHHS into the database, including the handling of shorelines crossing the dateline, etc (e.g. Eurasia continent definition). Yes, this is on my TODO-list, and no, it's not on top. To make the long story short: Don't expect GSHHS shorelines consistent with the rest of our data with the next scenery release. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
On Fri, Mar 21, 2008 at 11:00 AM, AnMaster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > It does indeed look like 0.9.8 had best coast line. Why is it so much > worse in more recent > scenery? Wouldn't it be possible to get the same good coastline as in > 0.9.8? As with anything, it's not quite that simple. The GHSSH coastline database (used in 0.9.8) is indeed more accurate for ocean coastlines. However, for any inland fresh water, it is much worse/less detailed than vmap0. So in 0.9.8 we used GHSSH for coastlines and VMAP0 for lakes & rivers. However, we found that there were major discrepancies between the two databases. For instance, lake washington near seattle is classified as lake by GHSSH and ocean by vmap0, so it simply did not appear in 0.9.8. Similarly there were things that were classified as ocean by GHSSH and lake by vmap0 so they were both drawn on top of each other. The decision was made to go with vmap0 entirely. We gave up accuracy around the coast lines, but we gained a much more consistent picture of the world ... with no major missing bits and no overlapping sections. Originally we only used GHSSH defined waterways, but this let to major problems, like the great lakes only being half defined (i.e. the canadian side of the lakes was not mapped so there was only land there.) And strangely, some Canadian's complained about that! :-) So we went to the mixed GHSSH-Ocean/VMAP0-fresh-water scheme, but people complained about the missing water that fell in the gaps between both dataset classifications. So then we went to vmap0, but now people are complaining about less detailed coast lines! What combination should we try next? :-) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It does indeed look like 0.9.8 had best coast line. Why is it so much worse in more recent scenery? Wouldn't it be possible to get the same good coastline as in 0.9.8? Regards, Arvid Norlander gerard robin wrote: | On jeu 20 mars 2008, gerard robin wrote: |> On jeu 20 mars 2008, Alex Romosan wrote: |>> Ralf Gerlich <[EMAIL PROTECTED]> writes: |>>> Scenery V1.0.0 has been built using VMAP0 landmass and shoreline data. |>> scenery v0.9.8 was also built with the vmap0 landmass and shoreline |>> data. |>> |>> looking at: |>> http://mapserver.flightgear.org/openlayers_sfobay.html?zoom=13&lat=37.862 |>> 84 &lon=-122.28796&layers=B0TFFTFTT (this is the bay area). i am not |>> really sure how to interpret the |>> colours but if you look at the berkeley coastline in v1.0.0 you'll see |>> that the berkeley marina is missing, big chunks of alameda are also |>> missing, and so on. on the above map it looks like the actual coast is |>> outlined in a red line, then there is some white (same as the water) |>> and then there are the red and green chunks (which is the scenery in |>> v1.0.0). the berkeley marina is present in 0.9.8 (but it disappeared |>> in subsequent scenery releases). something is wrong (and it's been |>> wrong for a long time). it will be interesting to compare the current |>> algorithm with the one used to generate the coastline in 0.9.8 to try |>> to understand why all these things have disappeared. |>> |>> --alex-- |> Hello, |> |> Regarding Hong-KongLat 22.296 deg and Lon 113.898 here are snapshots: |> |> That one from mapserver.flightgear.org |> |> http://pagesperso-orange.fr/GRTux/mapserver.flightgear.org_Hong-Kong.jpg |> |> That one with 0.9.8 scenery |> http://pagesperso-orange.fr/GRTux/Scenery-0.9.8_Hong-Kong.jpg |> |> And That one with 1.00 scenery |> http://pagesperso-orange.fr/GRTux/Scenery-1.00_Hong-Kong.jpg |> |> You could notice that apt VHHH is now , not an island but on full ground |> area |> |> Cheers | | And with 0.9.10 which is not so good than 0.9.8 about Hong Kong bay (we don't | see it here), but in any case better than 1.00 | | http://pagesperso-orange.fr/GRTux/Scenery-0.9.9_Hong-Kong.jpg | | | -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH49udWmK6ng/aMNkRCjeyAJ47EFUTl0kaN1kc6P3vxMXfGQtHvACgnUdt Poxjoybo+F7c0BaTeJCi46c= =mLOI -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi all! gerard robin wrote: [SNIP] > You could notice that apt VHHH is now , not an island but on full ground area Thanks for the reports. For your information: From the VHHH-tile I was actually able to identify the actual trigger for the buggy tiles. The trigger does lie in the modifications. Note that I'm talking about the "trigger", not about the "origin", as the part of the algorithm I modified actually is robust and correct - in contrast to the old version of that algorithm. I was able to verify that the data the modified part of the algorithm delivers is correct even in the case of the buggy tiles, but the rest of the TerraGear build chain cannot handle these correct results. The seemingly obvious "fix" - reverting to the old algorithm - isn't a fix. The reason for the modification in the first place were tiles consistently failing to build, without a workaround or other fix. Here the old algorithm was not robust enough for the data it got. Reverting to the old algorithm would therefore make these failed tiles reappear. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
