What is the precision of STK terrain from AGI? - cesiumjs

AS we are using STK terrain in CesiumJS, I am wondering what is the precision of the terrain data?
I guess STK is also generated from DEM, and the precision in different parts of the world is definitely different. But is there a specific number? Like DEM data, there is a number like resolution to evaluate the precision. What about it for STK World Terrain?

CesiumJS hasn't been using STK World Terrain in over a year, they switched to their own Cesium-ion-based terrain server. But I believe they seeded it with STK World Terrain (with AGI's permission, as they spun out from AGI) and have been augmenting it little by little since then.
I asked around (internally to AGI) and got this response from someone who works on STK and terrain:
The resolution of the terrain hosted by the STK Terrain Server (now superceded by Cesium ion and GCS) was 3-10m Continential US, 30m between 60N-60S, 1000m otherwise.
So, this means the resolution is variable. Some areas have higher resolution than others, but this should give some idea of the range available.

Related

Which DEM format is efficient .tiff or .hgt

I know is a vague question, but I've no expertise in GIS world. I was building this terrain map for a game like simulation project that i'm invested in. Data accuracy is least or no concern, but the quality of the terrain it generated. I'm not storing 27GB of data, instead i'm procedure'ly generating the height maps, from low quality SRTM30(couple of GB) as i need them. I use mainly gdal and interpolation( Kriging), numpy and some scikit learn. But i was unable to do this in real time.
My question is this, which DEM format is most suitable for gdal or an expensive loop to work with, to produce close real time result. Is their other choices?.

How to detect the exact geographic location of a site visitor

We have a tool on our travel site which should exactly calculate the distance from the visitor location to a given hotel which is known bye longitude and latitude. To achieve this we use google API but this is not accurate, some time the visitor location is about 40/50 km from the real location. According to other coders is not possible to do better. I can't believe that there is no the possibility to detect the exact geographic location of visitor. I have seen there are some other similar question but those are 2/3 year old.
Thank you
the location of a device can be obtained in two ways, by means of GPS or by means of the approximate location of the IP. The GPS reception can be affected by various factors .. in the cities is of some importance to the Urban Canyonin ie the reflection of the GPS waves on buildings. these factors can lead to an error of several meters and particularly unfavorable circumstances even of some tens of meters .. Another mode of detection is based on the geo-referencing of the IP and on routing that uses the device through wifi networks or data connections in this case the error on the position is normally a few tens of meters ..

GoogleMapApi looses precision depending the country you execute

I'm using http://code.google.com/p/php-google-map-api/. I made an application to get latitude and longitude of different street names. But when I execute this script from outside my country this precision is lost and I can't geolocate all the streets.
I think that Google keeps a different index depending of the country you are. How can I change the country (or locale) of my API?
Once we had an experiment on Mobile Network Development. We used GoogleMaps as basic geolocation tool for mapping/locating and measuring Base Stations characteristics. As the result, we've got into trouble very quickly.
We needed rather precise data (about 5 meters maximum deviation) and what do you think ? The street which was 2 km long (what was measured after experiment with required accuracy) was calculated as 1.7 km in GoogleMaps.
Moreover, most of the patches (ground photos) that are shown on map, overlaps each other in different way. Actually, it depends on country and on the precision of shooting, because some countries are more detailed some are not (very not).
Speaking about streets, this deviation is rather considerable to say that it can be precise. GoogleMaps should not be treated as the precise geolocation tool in any case, especially if high precision is required (street level is already above-normal precision).
So, I propose you not to take into account this data very seriously. Otherwise GoogleMaps is a very nice security breach for all of us. Imagine that You have nuclear bomb or missle and you already know where to direct it with accuracy of several meters, sitting somewhere in the middle of the Sahara. Here you are ...

Bing Maps API - SQL - geometry vs geography type

I'm developing a Mapping Service with Bing Maps AJAX API and SQL Server 2008. The question which appears to me is should I use the geography or geometry data type. I researched a lot but doesn't found a satisfactory answer. Here are some links about the topic:
SQL 2008 geography & geometry - which to use?
http://www.mssqltips.com/tip.asp?tip=1847
https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/
If I compare the two types I see the following points.
pro geography
consistent distance calculation around the world (time line!)
the coordinate system of the database is the same as the one which is used to add data to a map with the Bing Maps API (WGS84)
precise
contra geography
high computational costs
data size constrained to one hemisphere
missing functions (STConvexHull(), STRelate(),...)
pro geometry
faster computation
unconstrained data size
contra geography
distance units in degree (if we use WGS84 coordinates)
The problem for me is that I don't need a fast framework, a great coverage (the whole world) and high functionality. So I would prefer the geometry type.
The problem with the geometry type is, that I have to transform my data into a flat projection (Bing Map use SRID=3875), so that I get meters for the calculation. But when I use the Bing Maps projection (3875) in the database I have to transform my data back to WGS84 if I won't to display it in the map.
You've provided quite a good summary of the differences between the two types, and you've correctly identified the two sensible alternatives to be either geography(4326) or geometry(3857), so I'm not quite sure what more information anyone can provide - you just need to make the decision yourself based on the information available to you.
I would say that, although the geometry datatype is likely to be slightly quicker than the geography datatype (since it relies on simpler planar calculations, and can benefit from a tight bounding box over the area in question), this increase in performance will be more than offset by the fact that you'll then have to unproject back to WGS84 lat/long in order to pass back to Bing Maps - reprojection is an expensive process.
You could of course store WGS84 angular coordinates using the geometry datatype, but this is really a hack and not recommended - you are almost certain to run into difficulties further down the line.
So, I'd recommend using the geography datatype and WGS84. With careful index tuning, you should still be able to get sub-second response time for most queries of even large datasets. Incidentally, the "within a hemisphere" rule is lifted for the geography datatype in SQL Denali, so that limitation goes away if you were to upgrade.

Differences of geolocation accuracy between browsers

I try to know why when I use the geolocation with differents browsers on a same computer I have differents results. I know the implementation of the feature is not perfect..but,
it's strange because I try on a computer with chrome and FF4.1 and i got a good accuracy. On the same computer IE give me a bad accuracy. When I try on an other computer with chrome and FF 4.1, Chrome give me a good result and firefox the same bad accuracy as IE (ip location i guess ).
If anyone have a solution to get the same accuracy for all browser or just an explication ?
Let's assume the location is computed using Google Street informations (wifi hotspots and cell phone repeaters).
For wifi, the geolocation module looks at signals received by the wifi adapter. Those signals are emitted from wifi access points. Google cars assessed the emission power of each access points, as well as their location, when driving around. From the relative strength of the signals received by the user wifi adapter, which is available to the geolocation module, the location of the wifi access points in sight, and their assumed transmission power, it is easy to determine where the user's wifi adapter is located.
However the computed position will varies if one of the received access point varies its own power, or is shadowed by something between it's antenna and the receiver's antenna.
Note that this will be similar when the geolocation is computed using cell phone signals.
If the location is done using GPS signal with a GPS receiver embedded in the computer, then your are back to general issue of GPS position determination (number of satellites in sight, their relative position, their height on the horizon, and signal reflexion). GPS normal accuracy is "within a radius of 30 m", that is 60 meters / 200 ft.
If the location determination is done using a mix of all available techniques, then the result will varies also according to the weight assigned to each technique in the final result.