Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[KW71]

I noticed some of the same things, giving me the impression that many rivers were off by a few meters. Also, many river sections "miss" each other, and the ends, instead of joining cleanly, are mismatched sometimes horizontally, sometimes vertically, sometimes both.

I was just flying to different areas of the world and exploring such places, when I saw Josem75's post, and it seems a common occurrence.

Also sharp bends in rivers tend to cause land artifacts/errors. (just like roads can)

It will be interesting to see how this changes as the various problems are addressed and the data refined.

Many, if not all, of this errors may be caused by bad OSM data.

[HiFlyer]

I noticed some of the same things, giving me the impression that many rivers were off by a few meters. Also, many river sections "miss" each other, and the ends, instead of joining cleanly, are mismatched sometimes horizontally, sometimes vertically, sometimes both.

I was just flying to different areas of the world and exploring such places, when I saw Josem75's post, and it seems a common occurrence.

Also sharp bends in rivers tend to cause land artifacts/errors. (just like roads can)

It will be interesting to see how this changes as the various problems are addressed and the data refined.

Many, if not all, of this errors may be caused by bad OSM data.

Probably but one wonders how to address it. Cross-checking with other databases? Rules within Outerra that compensate? Is there much better osm data out there? Are there things that can be used besides osm for river data? As I said, it will be interesting to see how these things are solved.

In a way, the devs are following in the footsteps of X-plane, which also had to wade its way into the OSM swamp and dig for diamonds. They eventually came up with a ruleset that created "plausible" data from the base OSM mess.

I followed that pretty avidly as well. http://developer.x-plane.com/2011/12/where-is-my-water-the-roadmap-for-osm-and-vectors/

[KW71]

Indeed I already started to fix some nodes, especially those where rivers don't match: streams/waterways have to be connected, not just a stream with the polygon wich defines the shape.

We just need to be careful and (read &) follow the rules. Here is a good guide:

http://wiki.openstreetmap.org/wiki/River

[HiFlyer]

Indeed I already started to fix some nodes, especially those where rivers don't match: streams/waterways have to be connected, not just a stream with the polygon wich defines the shape.

We just need to be careful and (read &) follow the rules. Here is a good guide:

http://wiki.openstreetmap.org/wiki/River

Since the germans are known as the most dedicated OSM enthusiasts out there, I've been doing a lot of exploring in Germany (and yes, the networks are great!)

It seems like a natural place to suggest for a showcase scenery if Outerra ever does one.

One thing I do notice however is width. Many rivers etc (Like the Rhine, for instance) are noticeably thinner than in real life.

[krz9000]

These fixes should be done with the open street map editor I guess.

The Starnberg lake has an interesting thing going on. The osm mappers choose to create a detailed outline tagged as a lake but also used splines for the river that goes through the lake. Currently only the river is in outerra but not the lake based on its outline. I guess currently we only get splined rivers with width tags?

[cameni]

Yup, only rivers are currently present, and some smaller lakes that the splined river system can still support. Lakes will be done differently from satellite data, independent of OSM. Though, some smaller lakes are not present in satellite data that are acquired from wide band reflectance data, assuming they are too shallow or overgrown with vegetation.

[HiFlyer]

Hudson river is a mess. Looks like it will be a nightmare to fix.......

Sea level waterways and the new rivers don't seem to like each other.

[cameni]

Rivers that are wider than ~60m (at least 2 pixels in 30m satellite maps) will be handled by the lake system, which will also generally handle water levels on terrain. There should not be a conflict between rivers and seas then.

[HiFlyer]

Rivers that are wider than ~60m (at least 2 pixels in 30m satellite maps) will be handled by the lake system, which will also generally handle water levels on terrain. There should not be a conflict between rivers and seas then.

Its like watching a detective movie. I see things and wonder what you will do to escape the problem. Then I go off and look at what others have done. 

[josem75]

Rivers that are wider than ~60m (at least 2 pixels in 30m satellite maps) will be handled by the lake system, which will also generally handle water levels on terrain. There should not be a conflict between rivers and seas then.

It seems then that lakes will have real water like sea?
PD: So maybe big rivers too?

[cameni]

Eventually everything will have a real water
I wasn't going to implement underwater rendering for rivers, because once the lake system is done, vector rivers will also use it for the final rendering (and physics).

[krz9000]

cameni...whats the benefit of using so many datasources and not lets say take everything from OSM if its there? is it the lack of completeness? i would assume the osm dataset connects everything reasonably and if not it can be fixed fast. to have multiple sources creates all these potential gaps no?

[cameni]

OSM is incomplete and inconsistent, fixing it will require a lots of community effort. It's not reasonable to think it will be done anytime soon. Also, even if it was complete and clean tomorrow, as a map source it still lacks data like altitude above sea level that's needed for 3D reconstruction but not necessary for maps. And given the inconsistencies in the existing data, it would not be something we could rely upon. Fixing all the mess in the data is what takes most of the time spent on the importer by far.

During the OSM river import we are querying our elevation data to ensure 2D features match with the terrain.
If all seas, lakes and rivers were defined in OSM, we could use that to build the water level layer instead of using satellite reflectance data, but we'd still have to look up into the elevation data to determine the water levels.

We prefer more reliable data like satellite imagery that contains the water masks, but these are in lower resolution than proper OSM data and suffer from aliasing and filtering. One of the possibilities is to combine the two into a higher detail water mask map, so that we'd have ~30m resolution water bodies for the whole world, and finer shapes where they are available in OSM. However, this also brings in all the problems of OSM - it's not easy to determine algorithmically which OSM entities are erroneous and would actually introduce artifacts, and which ones are a refinement and can replace the rough raster data.

[krz9000]

thx cameni for the quick answer. i see your perspective...you have actual use-cases that need plausible data short term. in my personal dream about outerra it would be a OSM visualizer, just because i think the worlds data cannot be cleaned up without crowd-sourcing it....but this takes way too long for your actual use-cases i guess. anyway keep up the good work! its always exciting to to see what you do

[HiFlyer]

My question is about view distance. Ocean-based water seems to have effectively infinite view distance, while rivers have a relatively short one where large sections can appear abruptly as you are traversing an area at higher altitude.

Even changing terrain quality to 1080p doesn't completely address this.

Is this something that's expected to change, or even something that can already be changed in settings?