[Flightgear-scenery] Bolivia OSM Shapefiles

[HB-GRAL]

Hi all

As you can read in the log of the IRC meeting 2012-03-11 we are trying
to evaluate an isolated region to see what comes up with OSM data.
Bolivia was chosen by accident for the moment.

I’m not aware how the current OSM data on the scenery mapserver has been
imported, so I did a new import/export with recent data, distributed by
geofabrik.de. It is raw data as it is, but the shapefiles are splitted
by queries into

LINE:
- Canal, River, Stream
- Motorway, Primary, Secondary, Tertiary, Trunk, Road, Track, Residential
- Taxiway, Runway
- Railway

POLYGON:
- Industrial
- Residential
- Lake, Wetland

This data is only for evaluation purposes and scenery created with this
data can’t be distributed under GPL license.

Proposal for this evaluation:

- What OSM features are available ? What makes sense for scenery
creation ? (The data holds a pre-selected set of features, better or
more ideas?)

- Should OSM data be evaluated for every region/country/source ?

- Comparing to recent flightgear world scenery (vmap0?) shapes, do we
get better roads here ?
(There are some cases i.e. Australia where vmap0_roads are probably
better than OSM, but this was only evaluated on the flightgear
mapserver, without further knowledge what OSM data has been imported there)

- What is missing for consistent scenery creation with this sample data
? I.e. roads/rivers width ? Others ?

- What steps are needed to get topologically clean data for FlightGear
scenery creation tools, terragear-cs ?

Feel free to download this data here (~10 MB):
http://download.fgx.ch/data/bolivia-osm-2012-03-12.zip
I recommend Quantum GIS (QGis) or equal for browsing this data and
comparing to other sources (http://www.qgis.org).

Evaluating this "model" data and participation in this scenery
discussion is welcome anytime.

Cheers, Yves

[Maxime Guillaud]

Hi all,

I can share some of my recent experience trying to build detailed scenery for Europe
recently:

HB-GRAL <***@sablonier.ch> wrote:
> - What OSM features are available ? What makes sense for scenery
> creation ? (The data holds a pre-selected set of features, better or
> more ideas?)

My experience (from last year, so things might have changed) with those shapefiles is that
they are missing important information such as the bridge/tunnel attributes, making them
useless to generate scenery.

My solution was to start from the raw .osm data, and to process it through osmosis
(http://wiki.openstreetmap.org/wiki/Osmosis) to reduce its size while preserving the
tags relevant to scenery generation, before importing everything in a PostGIS database. I
can post my osmosis filter later today when I get home - the syntax is a bit tricky.

At some point I also tried to directly import the whole europe.osm.pbf file directly into
PostGIS without going through osmosis, but my (rather beefy, 8GB RAM and plenty of SSD
storage) machine was choking on it. I do not recommend this for large datasets.

> - Comparing to recent flightgear world scenery (vmap0?) shapes, do we
> get better roads here ?

In the zones I considered (Europe), the answer is most definitely yes.

> - What is missing for consistent scenery creation with this sample data
> ? I.e. roads/rivers width ? Others ?

The road width can be inferred from their class (highway/primary/secondary/etc...). I
have set up some criterion that I will also post here soon.

> - What steps are needed to get topologically clean data for FlightGear
> scenery creation tools, terragear-cs ?

- My experience is that the CORINE 2006 dataset is topologically clean - this was NOT the
case for CORINE 2000.

- The OSM data has some self-intersecting lines that need to be cleaned up, and this is
feasible in PostGIS.

The stumbling point for me at this point is that fgfs-construct still crashes from time
to time, however after many attempts at debugging this, I believe that this can not be
attributed to the data, but to the algorithms itself. When this is fixed, I have
gigabytes of data for Europe scenery lying around ready to be processed.

Maxime

[Maxime Guillaud (by way of Maxime Guillaud )]

***@sablonier.ch wrote :
> This shapefiles are not shapefiles from regular OSM data distributors.
> I created this ones myself, after .osm import to postgres, so it
> contains all or another selection of .osm information available.

Sorry Yves, I looked at the content of the zip file but could not open the shapefiles on
that machine. My comment relates to the shapefiles from the Geofabrik website.

Now here is more information about what I wrote before:

Maxime Guillaud <***@mguillaud.net> wrote :
> My solution was to start from the raw .osm data, and to process it through osmosis
> (http://wiki.openstreetmap.org/wiki/Osmosis) to reduce its size while preserving the
> tags relevant to scenery generation, before importing everything in a PostGIS database.
> I can post my osmosis filter later today when I get home - the syntax is a bit tricky.

here is the osmosis command that achieves the above: it merges two files (Europe and the
Canary islands), and selects the "highway", "junction", "railway" and "tunnel" tags only:

osmosis -v --read-pbf /storage1/OSMmaps/canary_islands_20110921.osm.pbf
--read-pbf /storage1/OSMmaps/europe_20110921.osm.pbf --merge --wkv
keyValueList="highway.motorway,highway.motorway_link,highway.trunk,highway.trunk_link,highway.primary,highway.primary_link,highway.secondary,highway.secondary_link,highway.tertiary,highway.unclassified,highway.residential,highway.rest_area,junction.roundabout,railway.rail,tunnel.yes,tunnel.1"
--tf reject-relations --used-node
--write-pbf /storage2/tmp/europe_and_canary_20110921_roadsonly.pbf


> The road width can be inferred from their class (highway/primary/secondary/etc...). I
> have set up some criterion that I will also post here soon.

For this, I came up with the following SQL queries to populate tables containing
respectively the 12m-wide, 8m-wide, 6m-wide and 4m-wide roads, and railways:

INSERT INTO fg_roads_12m (the_geom) SELECT
(ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
highway IN ('motorway','trunk') AND (tunnel ISNULL) AND railway ISNULL;

INSERT INTO fg_roads_8m (the_geom) SELECT
(ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
highway IN ('primary') AND (tunnel ISNULL) AND railway ISNULL;

INSERT INTO fg_roads_6m (the_geom) SELECT
(ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
highway IN ('motorway_link','trunk_link','primary_link','secondary') AND (tunnel ISNULL)
AND railway ISNULL;

INSERT INTO fg_roads_4m (the_geom) SELECT
(ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
highway IN ('secondary_link','tertiary') AND (tunnel ISNULL) AND railway ISNULL;

INSERT INTO fg_railroads (the_geom) SELECT
(ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
railway IN ('rail') AND (tunnel ISNULL);


> - My experience is that the CORINE 2006 dataset is topologically clean - this was NOT
> the case for CORINE 2000.

Regarding the mapping of CORINE to flightgear textures, I am using the correspondance
detailed in the attached table (corine-mapping.txt). In order to see the relative
importance of each landcover type in the europe dataset, the table also contains the
surface that they occupy, in % relative to the total of the land surface (excluding
oceans).

Some more remarks about CORINE:

- the latest release of the CORINE 2006 data (August 2011) has Malta in the wrong
location (!). I reported that to the European Environment Agency already, and they are
planning a new release:
http://community.eea.europa.eu/home/environmental-topics/land-use-soil/hello-i-downloaded-the-latest-release-version-15-from-august-2011-of-the/view

- the available CORINE 2006 data does not include Greece. While trying to piece together
the CORINE 2006 dataset and the CORINE 2000 data around Greece, I noticed that it is
better to cut along horizontal or vertical (in fact, latitude or longitude) lines,
since oblique cuts often introduce some topological inconsistencies.

I hope these few remarks help - do not hesitate to ask for details. It's not always
easy to transfer this kind of practical experience with the scenery tools!

Maxime

--
sent from my armchair

[HB-GRAL]

Hi Maxime

First of all thank you very much for sharing your experience here and
posting your code.

Am 14.03.12 21:59, schrieb Maxime Guillaud (by way of Maxime Guillaud
<***@mguillaud.net>):
>
> here is the osmosis command that achieves the above: it merges two files (Europe and the
> Canary islands), and selects the "highway", "junction", "railway" and "tunnel" tags only:
>
> osmosis -v --read-pbf /storage1/OSMmaps/canary_islands_20110921.osm.pbf
> --read-pbf /storage1/OSMmaps/europe_20110921.osm.pbf --merge --wkv
> keyValueList="highway.motorway,highway.motorway_link,highway.trunk,highway.trunk_link,highway.primary,highway.primary_link,highway.secondary,highway.secondary_link,highway.tertiary,highway.unclassified,highway.residential,highway.rest_area,junction.roundabout,railway.rail,tunnel.yes,tunnel.1"
> --tf reject-relations --used-node
> --write-pbf /storage2/tmp/europe_and_canary_20110921_roadsonly.pbf
>

For Bolivia there are much features covered with i.e. with 'road' too,
and I explored also 'track'. Track can be skipped, yes, to much detail.
But I was thinking about pipelines and other significant lines.

Anyway, another topic. I noticed that QGis allows a simple way to
explore some inconsistency in data. In advanced search of the table view
one can browse all feature entities for one feature column. This helped
me to see how OSM contributors are classifying. I fear we have to think
about. It looks like this differs from country to country or from region
to region ... It will be a manual task to verify data for each country.

btw. more technically, how much data did you get with osmosis task
compared to europe origin .osm.pdf ? Just as a base for benchmark
departement ;-)

>
>> The road width can be inferred from their class (highway/primary/secondary/etc...). I
>> have set up some criterion that I will also post here soon.

This will be nice. In Bolivia example I see some features have width,
depends on OSM contributors/data origin.

>
> For this, I came up with the following SQL queries to populate tables containing
> respectively the 12m-wide, 8m-wide, 6m-wide and 4m-wide roads, and railways:
>
> INSERT INTO fg_roads_12m (the_geom) SELECT
> (ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
> highway IN ('motorway','trunk') AND (tunnel ISNULL) AND railway ISNULL;
>
> INSERT INTO fg_roads_8m (the_geom) SELECT
> (ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
> highway IN ('primary') AND (tunnel ISNULL) AND railway ISNULL;
>
> INSERT INTO fg_roads_6m (the_geom) SELECT
> (ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
> highway IN ('motorway_link','trunk_link','primary_link','secondary') AND (tunnel ISNULL)
> AND railway ISNULL;
>
> INSERT INTO fg_roads_4m (the_geom) SELECT
> (ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
> highway IN ('secondary_link','tertiary') AND (tunnel ISNULL) AND railway ISNULL;
>
> INSERT INTO fg_railroads (the_geom) SELECT
> (ST_Dump(st_union(st_multi(way),st_pointn(way,1)))).geom FROM planet_osm_line osm WHERE
> railway IN ('rail') AND (tunnel ISNULL);
>

Thanks a lot for posting this queries. Think this stuff should go to
scenery creation documentation ASAP.

>
>> - My experience is that the CORINE 2006 dataset is topologically clean - this was NOT
>> the case for CORINE 2000.

I have no experience with Corine data myself. Others stated here that
also Corine 2006 was not topologically clean. Does it depend on data
distributor ? Are there some differences ?

>
> Regarding the mapping of CORINE to flightgear textures, I am using the correspondance
> detailed in the attached table (corine-mapping.txt). In order to see the relative
> importance of each landcover type in the europe dataset, the table also contains the
> surface that they occupy, in % relative to the total of the land surface (excluding
> oceans).

Very, very valuable stuff you post here.

>
> Some more remarks about CORINE:
>
> - the latest release of the CORINE 2006 data (August 2011) has Malta in the wrong
> location (!). I reported that to the European Environment Agency already, and they are
> planning a new release:
> http://community.eea.europa.eu/home/environmental-topics/land-use-soil/hello-i-downloaded-the-latest-release-version-15-from-august-2011-of-the/view

:-)

>
> - the available CORINE 2006 data does not include Greece.

"Greece unfortunately was not able to start production." I guess they
had other problems than Corine Landcover, unfortunately :-(


> While trying to piece together
> the CORINE 2006 dataset and the CORINE 2000 data around Greece, I noticed that it is
> better to cut along horizontal or vertical (in fact, latitude or longitude) lines,
> since oblique cuts often introduce some topological inconsistencies.
>
> I hope these few remarks help - do not hesitate to ask for details. It's not always
> easy to transfer this kind of practical experience with the scenery tools!
>
> Maxime

One of the most informative post I’ve ever seen in this area, and very
valuable for further discussion. Thank you very much !

Cheers, Yves

[Maxime Guillaud]

Hi Yves,

HB-GRAL <***@sablonier.ch> wrote :
> Anyway, another topic. I noticed that QGis allows a simple way to
> explore some inconsistency in data. In advanced search of the table view
> one can browse all feature entities for one feature column. This helped
> me to see how OSM contributors are classifying. I fear we have to think
> about. It looks like this differs from country to country or from region
> to region ... It will be a manual task to verify data for each country.

Another useful trick in QGIS is that the style (color, line width...) of a given
feature can be a function of one column of the table. Practically, you can simply change
the appearance of a line based on its highway=... tag (or make them disappear
selectively), without fiddling with SQL requests. Go to the properties menu of the layer
in question, select style->categorized, and select the "highway" column for the
categorization.


> btw. more technically, how much data did you get with osmosis task
> compared to europe origin .osm.pdf ? Just as a base for benchmark
> departement ;-)

The size of the .pbf file went from 6.5 GB to 1.2 GB after the osmosis filtering.
Currently my database of OSM line data for Europe (motorways down to
unclassified/residential roads, but no tracks/paths) contains just over 11 million
features.

Note that the osmosis filter is only selecting which features go through. When a feature
passes through the filter, all its tags are kept, some of which are useless (and would
create a bunch of useless columns in the database). This can be filtered by osm2pgsql
during the import: I have a custom style file for osm2pgsql to import only the
relevant tags in the PostGIS database. It is attached to this message.


> This will be nice. In Bolivia example I see some features have width,
> depends on OSM contributors/data origin.

My experience is that the rendering is not accurate enough for this information to be
really made use of. I would say don't bother, and change it later if you really miss it ;)

> I have no experience with Corine data myself. Others stated here that
> also Corine 2006 was not topologically clean. Does it depend on data
> distributor ? Are there some differences ?

I have no idea about that. Where was it stated that CORINE 2006 is not topologically
clean, and on what grounds ?

Maxime


--
sent from my armchair

[HB-GRAL]

Am 14.03.12 15:20, schrieb HB-GRAL:
>
> LINE:
> - Canal, River, Stream
> - Motorway, Primary, Secondary, Tertiary, Trunk, Road, Track, Residential
> - Taxiway, Runway
> - Railway
>

Maybe I miss somthing, but I see no answer about using OSM line features
mentioned here. Is there any experience using features like "Canal,
River, Stream" from OSM, or "Taxiway/Runway" or "Railway" ?

Cheers, Yves

[Maxime Guillaud]

Hi Yves,

HB-GRAL <***@sablonier.ch> wrote:
> Maybe I miss somthing, but I see no answer about using OSM line features
> mentioned here. Is there any experience using features like "Canal,
> River, Stream" from OSM, or "Taxiway/Runway" or "Railway" ?

Large water features (canals, large rivers) are captured in the CORINE data. Small water
features will be very hard to render in a realistic manner, and in my opinion OSM is not
really going to help in this regard.

Runways/taxiways are well handled by genapts (especially with version 8.50 of apt.dat),
and anything in OSM is probably of lower quality.

OSM has usually very accurate railway information. I have used it without
problems in my custom scenery http://wiki.flightgear.org/index.php/Custom_France_Scenery .

Maxime

[Gijs de Rooy]

OSM canals are definitely not useless! CORINE doesn't capture all these canals in Amstedam, only OSM does it like this:
https://lh5.googleusercontent.com/-sWxZvVodMCo/S19O2SBMKeI/AAAAAAAABEM/yHURosg4xVM/s1024/fgfs-screen-003.png

Roads are nice as well, but I think that's widely known :)
https://lh3.googleusercontent.com/-pBvAteO37g0/TnTVRL_KFtI/AAAAAAAACYw/GOjuUrFNtdk/s1362/4.png


Cheers,
Gijs

[HB-GRAL]

Am 21.03.12 10:16, schrieb Maxime Guillaud:
> Hi Yves,
>
> HB-GRAL<***@sablonier.ch> wrote:
>> Maybe I miss somthing, but I see no answer about using OSM line features
>> mentioned here. Is there any experience using features like "Canal,
>> River, Stream" from OSM, or "Taxiway/Runway" or "Railway" ?
>
> Large water features (canals, large rivers) are captured in the CORINE data. Small water
> features will be very hard to render in a realistic manner, and in my opinion OSM is not
> really going to help in this regard.
>
> Runways/taxiways are well handled by genapts (especially with version 8.50 of apt.dat),
> and anything in OSM is probably of lower quality.
>
> OSM has usually very accurate railway information. I have used it without
> problems in my custom scenery http://wiki.flightgear.org/index.php/Custom_France_Scenery .
>
> Maxime
>

Hi Maxime

Yes, the CORINE case ... But the data I’m looking to here is from south
america and there is no Corine. There is only current flightgear scenery
versus OSM to check. The rivers don’t look that bad in this OSM region.
I discovered also some regions in asia where OSM water looks
interesting. Also not completely sure if taxiways/runways are of lower
quality in every case.

I’m going to setup a map where this cases can be verified on this south
american example.

Cheers, Yves

[Eugenio Mondini]

On Wed, Mar 14, 2012 at 03:20:40PM +0100, HB-GRAL wrote:
> Hi all
Hi Yves and everyone.
>
> As you can read in the log of the IRC meeting 2012-03-11 we are trying
> to evaluate an isolated region to see what comes up with OSM data.
> Bolivia was chosen by accident for the moment.
>
> I’m not aware how the current OSM data on the scenery mapserver has been
> imported, so I did a new import/export with recent data, distributed by
> geofabrik.de. It is raw data as it is, but the shapefiles are splitted
> by queries into
>
> LINE:
> - Canal, River, Stream
> - Motorway, Primary, Secondary, Tertiary, Trunk, Road, Track, Residential
> - Taxiway, Runway
> - Railway
>
> POLYGON:
> - Industrial
> - Residential
> - Lake, Wetland
>
> This data is only for evaluation purposes and scenery created with this
> data can’t be distributed under GPL license.
>
> Proposal for this evaluation:
>
> - What OSM features are available ? What makes sense for scenery
> creation ? (The data holds a pre-selected set of features, better or
> more ideas?)
>
> - Should OSM data be evaluated for every region/country/source ?

According to openstreetmap wiki [0] Bolivia has a different
conventions than my country Argentina [1] which is a neighbouring
country. Here in Argentina you have mostly avenues and roads
distinction because of speed limit, in avenues it is 60 km/h and in
roads is 40 km/h. So you have avenues drawn with tag highway=primary
and roads with tag highway=residential and then you have to add the
surface tag, so in my town in the same avenue you have all with
highway=primary and then in 10 blocks it changes from surface=paved
then surface=cobblestone and then sirface=unpaved. That does not show
up in mapnik tiles but should be in your data if you took it from
Argentina.

> - Comparing to recent flightgear world scenery (vmap0?) shapes, do we
> get better roads here ?
> (There are some cases i.e. Australia where vmap0_roads are probably
> better than OSM, but this was only evaluated on the flightgear
> mapserver, without further knowledge what OSM data has been imported there)
>
> - What is missing for consistent scenery creation with this sample data
> ? I.e. roads/rivers width ? Others ?
>
> - What steps are needed to get topologically clean data for FlightGear
> scenery creation tools, terragear-cs ?
>
> Feel free to download this data here (~10 MB):
> http://download.fgx.ch/data/bolivia-osm-2012-03-12.zip

As soon as I can I'll check if there are more things which could be
used that doesn't show up in mapnik.

> I recommend Quantum GIS (QGis) or equal for browsing this data and
> comparing to other sources (http://www.qgis.org).
>
> Evaluating this "model" data and participation in this scenery
> discussion is welcome anytime.
>
> Cheers, Yves
Thanks. Eugenio.

[HB-GRAL]

Am 21.03.12 15:51, schrieb Eugenio Mondini:
>>
>> Feel free to download this data here (~10 MB):
>> http://download.fgx.ch/data/bolivia-osm-2012-03-12.zip
>
> As soon as I can I'll check if there are more things which could be
> used that doesn't show up in mapnik.
>

Hi Eugenio

Many thanks for your post here. It will be very interesting comparing
bolivian data with neighbourhood data. One goal could be "to flatten"
definitions for the whole region when there is some overview about
different OSM conventions. I think your experience will be needed for
this region ... Anyway, knowing more about OSM conventions and "reality"
in each region will be very helpful for scenery projects dealing with
OSM data.

Cheers, Yves

[Eugenio Mondini]

On Thu, Mar 22, 2012 at 02:00:55PM +0100, HB-GRAL wrote:
> Am 21.03.12 15:51, schrieb Eugenio Mondini:
> >>
> >> Feel free to download this data here (~10 MB):
> >> http://download.fgx.ch/data/bolivia-osm-2012-03-12.zip
> >
> > As soon as I can I'll check if there are more things which could be
> > used that doesn't show up in mapnik.
> >
>
> Hi Eugenio
>
> Many thanks for your post here. It will be very interesting comparing
> bolivian data with neighbourhood data. One goal could be "to flatten"
> definitions for the whole region when there is some overview about
> different OSM conventions. I think your experience will be needed for
> this region ... Anyway, knowing more about OSM conventions and "reality"
> in each region will be very helpful for scenery projects dealing with
> OSM data.

I have checked the bolivian data but I have found that the 'surface'
tag is mostly unused. But I would expect that for most countries in
South America including Argentina where we do have a convention but
most editing is done for what is shown in the openstreetmap web except
for some work on bus lines. I think it would be too much work for
scenery to draw according to surface because of non standard tags, in
bolivian data you can see for example residential streets with surface
tag as 'ground', I'd think that someone meant dirt. And mostly the tag
stays NULL and you would have to start guessing about the kind of city
and region to determine if it would be logical to be asphalt or just
dirt. For example in my province a NULL surface tag would be more
probably guessed as cobblestone but in some big cities it should be
asphalt. And maybe if the tag is rendered as is it is an incentive
for local groups to fix it in openstreetmap itself for the next
scenery creation.

> Cheers, Yves
Thanks to all.

[Eugenio Mondini]

Obviously I forgot the links, sorry.
http://wiki.openstreetmap.org/wiki/Bolivia
http://wiki.openstreetmap.org/wiki/WikiProject_Argentina#Rutas

[HB-GRAL]

Am 14.03.12 15:20, schrieb HB-GRAL:
> Hi all
>
> As you can read in the log of the IRC meeting 2012-03-11 we are trying
> to evaluate an isolated region to see what comes up with OSM data.
> Bolivia was chosen by accident for the moment.
>
> I’m not aware how the current OSM data on the scenery mapserver has been
> imported, so I did a new import/export with recent data, distributed by
> geofabrik.de. It is raw data as it is, but the shapefiles are splitted
> by queries into

Hi all

There is some progress here creating new bolivian scenery with recent
terragear-cs (using genapts850 and reworked fgfs-construct, many thanks
to Chris and Peter and all other terragear-cs workers!).

>
> LINE:
> - Canal, River, Stream
(and many other features)

I compared OSM data with "Recursos Hidricos" shapes available here
http://essm.tamu.edu/bolivia/index_en.htm . Looks like I can get much
more detailed data from this resource for my experiment.

Experiment? I started to import river data as lines in grass and buffer
that data with width (estimated) to polygons instead of feeding lines to
Terragear. After buffering I use grass vector generalization algorithms
(snake, sliding) to get a more "natural" looking polygon output. This is
my personal water-features-creation-theory to get better looking
river/stream scenery.
Example: http://download.fgx.ch/screens/snakeslide.png

> - Motorway, Primary, Secondary, Tertiary, Trunk, Road, Track, Residential
> - Taxiway, Runway
> - Railway

Roads is the core of OSM and much more detailed than other available
data, I will take that from OSM and feed it as lines for my next
terragear-cs run. Makes me nervous.

>
> POLYGON:
> - Industrial
> - Residential
> - Lake, Wetland

Also here I get more recent data from the tamu.edu source above for the
moment. I clipping this shapes to topologically clean shapefiles
recently. "Topologically clean", the terragear word of the year ;-)

The first pass of a 4x4 degree chunk (with 8.50 airports, new
lake/forest and height data, but without OSM data) went very well using
the updated toolchain. I checked the scenery with FlightGear 2.6.0 and
it looks very nice.

Curtis, when you’re going to explain again the slope calculation to
someone else (me I got it now I think), maybe you can illustrate this
with this very interesting airport at Titicaca Lake here:
http://download.fgx.ch/screens/tititataaa.png) ;-)

Ok, I will update this 8.50 airport data, looks like it is to artificial.

This week I will start to generate the same 4x4 chunk with OSM data
included and make it available for everyone who is interested looking
into this data. And also when all my experiments fails, it’s a nice
experience here working for scenery again. And my updated shapefiles
from bolivia can come to flightgear scenery with or without OSM streets
later, it’s a huge update I guess for this region, compared to recent
available scenery data.

Cheers, Yves

[HB-GRAL]

Am 14.03.12 15:20, schrieb HB-GRAL:
> Hi all
>

Here is some reporting of thoughts/issues I get with compiling
residential roads http://downloads.fgx.ch/screens/lapazpainting.png at
bolivian/La Paz scenery;

- used urban shapefile is not accurate, and I need to add some sub-urban
areas and other classes
- AirportArea is rendered everywhere with default texture and gives
forest area, don’t know why recently, maybe I need to change
Materials/dds/materials.xml?
- Some "white" lines or areas seems not to be clipped correctly (?) <= 2 %
- The urban texture hides residential roads, maybe this texture needs a
replacement probably, also because of the new random buildings
- Random buildings density 5.0 is shown here (the max? of the slider)

Other problems, more grpahics card related ...
- Unfortunately Rembrandt is not working here on OSX/ATI 5750/1 GB VRAM
(framerate < 1), i can’t find futher instruction how to solve this
problems at the moment
- Most terrain still looks very dark compared to what I see on screens
coming from other cards (since fg 2.4.x)

(The clouds/sky/weather looks really fantastic !)

Cheers, Yves

[HB-GRAL]

Am 02.05.12 00:46, schrieb HB-GRAL:
> Am 14.03.12 15:20, schrieb HB-GRAL:
>> Hi all
>>
>
> Here is some reporting of thoughts/issues I get with compiling
> residential roads http://downloads.fgx.ch/screens/lapazpainting.png at
> bolivian/La Paz scenery;
>
> - used urban shapefile is not accurate, and I need to add some sub-urban
> areas and other classes
> - AirportArea is rendered everywhere with default texture and gives
> forest area, don’t know why recently, maybe I need to change
> Materials/dds/materials.xml?

I started to use Materials/default/materials.xml and create a own
/test/materials.xml.

> - Some "white" lines or areas seems not to be clipped correctly (?)<= 2 %

I use roads as polygon features now and not lines anymore. Gives less
faults, but still some very small no-texture-areas.

> - The urban texture hides residential roads, maybe this texture needs a
> replacement probably, also because of the new random buildings

"Hiding" means only visually of course. But I replaced the texture
anyway now to fit the region and to play around with random buildings
and residential roads. This becomes now looking like a city here,
without (almost) any shader activated.
http://download.fgx.ch/screens/lapaz_residential.png
(sorry, but this was live metar :-)

Because of residential roads you can start to identify "real" city areas
I think, no standard city soup anymore. I will add primary/secondary and
trunk again.

> - Random buildings density 5.0 is shown here (the max? of the slider)

Density has no impact anymore on FPS. This was very interesting. I had
the same FPS with random buildings density 1.0 or 5.0 (to be honest I
removed 50 of 107 shader files in /Shaders the hard way and commented
out <effect> lines for one hour, but it was worth doing that).

>
> Other problems, more grpahics card related ...
> - Unfortunately Rembrandt is not working here on OSX/ATI 5750/1 GB VRAM
> (framerate< 1), i can’t find futher instruction how to solve this
> problems at the moment

Still not able to run rembrandt with current git from today with my
card. But I’m looking forward to get it here, it’s under heavy
development I think. I am curious how the shadows will look at urban
areas/cities vs. building density.

> - Most terrain still looks very dark compared to what I see on screens
> coming from other cards (since fg 2.4.x)
>
> (The clouds/sky/weather looks really fantastic !)
>

Other side-effect of deactivating shaders was getting back more light on
my card for the moment. I know this is not fair to shader devs just
deactivating, but unfortunately I lost complete overview of the
effects/shader system.

(Ehrm, just as side-note Terrain-haze is broken here at the moment. But
I think I don’t need it anyway, it gives just some general colour sauce
over all the scenery. This is no fundamental critism, I’m just saying:
please no more "hidden" not switchable shaders, it will become very hard
i.e. for texture development etc.).

Cheers, Yves