Thanks Arno.
But I thought Christopher Columbus discovered that the Earth
wasn't flat ?
<...
just kidding, of course ! >
Apparently Sketchup performs the required re-projection when one geo-locates a (max 1024x1024 pixel) image tile directly from Google Earth via its
own internal engine.
Can that same internal engine in Sketchup be used to import
ex: a GeoTiff (treated as a generic Tiff I would assume), or a BMP file ?
I suspect that internal engine in Sketchup
can't be used by the end user to do this with any other image import process.
So, IIUC, if we import
non-georectified imagery into
ex: Sketchup to use as a background for tracing objects to be placed into FS
on the ground (ex: custom ground polys), what is a freeware application that end users could utilize to "re-project" or 'warp' the imagery
properly before import ?
I think we'd all like to be certain about this for FS Development, especially considering such issues as I've seen addressed in the Global Mapper forum:
http://globalmapperforum.com/forums/projection-questions/4612-flat-earth-projection-conversion.html
And regarding the making of large FS airport backgrounds / very
long RWYs etc, this was rather intriguing in its implications for would-be 3D modelers:
"
We need to decide: what is the acceptable difference between distance measured
on the ground and distance measured on the map.
Local ‘flat earth’ grids only work over a very small area. If your work area extends
beyond a kilometre, you can no longer use a localised flat earth grid. However, you
could define your own local map projection with a small (negligible, but acceptable)
scale-factor. It is relatively easy to convert data between your local projection and the
national grid.
If you are designing a long linear feature, it will usually have its own reference
system – chainage (i.e. distance from a known starting point), along the feature and
offset perpendicular to the feature. You could introduce a variable scale-factor, so that
chainage corresponds with what you measure on the ground. An even neater solution
would be to use what is commonly known as ‘snake’ projection: this dynamically
converts between chainage and grid co-ordinates on large, generally linear projects."
...
also to be considered:
"
in Great Britain, Ordnance Survey (ordnancesurvey.co.uk) provides
geodata referenced to a map projection known as British National Grid.
In most places, there will be a difference between a distance measured
on the ground. This difference is known as scale-error or scale-factor
distortion. It is variable depending upon location in the country, and can affect
measurements by an amount ranging between zero and 4cms every 100m."
http://www.rics.org/site/download_feed.aspx?fileID=272&fileExtension=PDF
https://communities.rics.org/gf2.ti...657_Map_Proj_Scale_Factor_1st_final_draft.pdf.
Thanks for your further clarification of what the proper name of that conversion / re-projection format is which we should look for in GIS apps, for subsequent 3D world modeling in GMAX / 3DSMAX and Sketchup with FS as the ultimate destination of such content.
PS: I see that Google Maps (AFAIK the same as Google Earth) says this about their projection and coordinate system:
"
Map Coordinates
There are several coordinate systems that the Google Maps API uses:
* Latitude and Longitude values which reference a point on the world uniquely. (Google uses the World Geodetic System WGS84 standard.)
* World coordinates which reference a point on the map uniquely
* Tile coordinates which reference a specific tile on the map at the specific zoom level
World Coordinates
Whenever the Maps API needs to translate a location in the world to a location on a map (the screen), it needs to first translate latitude and longitude values into a "world" coordinate. This translation is accomplished using a map projection. Google Maps uses the Mercator projection for this purpose. You may also define your own projection implementing the google.maps.Projection interface. (Note that interfaces in V3 are not classes you "subclass" but instead are simply specifications for classes you define yourself.)
For convenience in the calculation of pixel coordinates (see below) we assume a map at zoom level 0 is a single tile of the base tile size. We then define world coordinates relative to pixel coordinates at zoom level 0, using the projection to convert latitudes & longitudes to pixel positions on this base tile. This world coordinate is a floating point value measured from the origin of the map's projection to the specific location. Note that since this value is a floating point value, it may be much more precise than the current resolution of the map image being shown. A world coordinate is independent of the current zoom level, in other words.
World coordinates in Google Maps are measured from the Mercator projection's origin (the northwest corner of the map at 180 degrees longitude and approximately 85 degrees latitude) and increase in the x direction towards the east (right) and increase in the y direction towards the south (down). Because the basic Mercator Google Maps tile is 256 x 256 pixels, the usable world coordinate space is {0-256}, {0-256}"
http://code.google.com/apis/maps/documentation/javascript/maptypes.html
Hmmm... remarkably similar to the FS world quad matrix cell system of
ex: LOD-13 tiles having 256 x256 Area Points each cell !
But then, I've seen rumors posted that a number of folks with the original KeyHole / Google Earth team used to work for ACES.
This was a rather interesting "MS" Document as well:
Introduction to Spatial Coordinate Systems: Flat Maps for a Round Planet
http://msdn.microsoft.com/en-us/library/cc749633(v=sql.100).aspx
So, I guess we should also look at what MS 'Bing' Maps (aka MS Virtual Earth") uses too:
"
Map Projection
To make the map seamless, and to ensure that aerial images from different sources line up properly, we have to use a single projection for the entire world. We chose to use the Mercator projection, which looks like this:
Bb259689.150afcdc-99eb-4296-9948-19c0a65727a3(en-us,MSDN.10).jpg
Although the Mercator projection significantly distorts scale and area (particularly near the poles), it has two important properties that outweigh the scale distortion:
1. It’s a conformal projection, which means that it preserves the shape of relatively small objects. This is especially important when showing aerial imagery, because we want to avoid distorting the shape of buildings. Square buildings should appear square, not rectangular.
2. It’s a cylindrical projection, which means that north and south are always straight up and down, and west and east are always straight left and right.
Since the Mercator projection goes to infinity at the poles, it doesn’t actually show the entire world. Using a square aspect ratio for the map, the maximum latitude shown is approximately 85.05 degrees.
To simplify the calculations, we use the spherical form of this projection, not the ellipsoidal form. Since the projection is used only for map display, and not for displaying numeric coordinates, we don’t need the extra precision of an ellipsoidal projection. The spherical projection causes approximately 0.33% scale distortion in the Y direction, which is not visually noticeable."
http://msdn.microsoft.com/en-us/library/bb259689.aspx
GaryGB
