I have multiple point locations (in shapefile or CSV) over Europe. However, these points are in the Geographic Projection. Different points are located over Europe and thus each point has different UTM zones in QGIS/Arc.
The main reason to convert the points from GCS to UTM is to create a buffer with accurate distances.
Any support would be appreciated.
Thank you
Related
Using Google Map or any other map provider, if I have a GPS tracking device on a train, how do I get a railway distance between the train to the nearest train station?
If you are physically on the train and have a GPS tracked device, most mapping platforms won't be able to snap you to the railway line unless the device/user is sitting at a station. If the device is close enough to road, usually within 150 meters, it will likely snap to that. If the user was at a station, its much easier and just a matter of calculating a transit route.
That said, most transit data uses straight line distances between stations and not true travel distances. I've worked with many large transit agencies around the world and many of them don't even know where their railway lines run, let along the true distance between stations. What they do know is how long it takes to travel between stations and that's all they generally care about for the most part.
To do this correctly, you will need access to the raw railway line vector data. Open street maps has some, but I don't know how accurate or complete it is. Many agencies or governments publish this data, but often it is just straight lines drawn between stations, so you would have to look and see what's available. Once you have complete data, then you can snap to your GPS point to the nearest railway line then calculate the shortest path along all railway lines to the station in question. This is fairly complex, but I've done this before for both railway lines and private road networks. There are several open source libraries that can assist with this, like this one: https://github.com/perliedman/geojson-path-finder
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 ..
I need to retrieve the latitude and longitude coordinates of the intersection of a polygon with the street (look the blue point on the edge of the circle. image here!!!)
I need this data in order to calculate the road length from center of the circle, to its edge). Does anybody know if this task is possible, and if yes which technology allows for doing that ?
This works only if you have the vector data of all streets. This does not work with an image (jpg bmp).
When you have the vector data, you do a simple circle with line intersection, which you have learned in school.
You might transform the vectors first to a cartesian x,y plane such that you dont use latitude, longitude from the street vectors.
vector data, you can get for free from OpenStreetMap, or from TomTom or NavTeq when it is a huge project. Sometimes the state provides this data, too.
A common data format for such vector data is the ESRI shp file format. (.shp)
I recently worked on a small project on location-based services and my intention was to locate the nearest cab (GPS fitted) within a given radius of a requesting passenger (GPS enabled Android phone). I wanted to use MongoDB's geospatial indexes, but it turned out that geospatial indexes work on lat-longs and they calculate displacement between two points, not the distance. In my case, search was confined within a city, and I had to go for GoogleMaps Directions Service because it tells the distance as on the road, estimated time taken etc.
Does this mean that geospatial indexes make sense only when displacement is large enough, so that distance and displacement becomes essentially the same?
Geospatial indexes have the goal of having fast data retrieval based on position on a multi-dimensional space. If you have the cab position data in a MongoDB database you could use a geospatial index to fastly select a reduced set of cabs which are more likely to be the closest one, but still you'd have to calculate the distance on the road (and eventually the drive time) using an algorythm on the road network.
For example you know that if the closest (in straight line) cab is at 20km from you (measured through the road), you know that any cab outside the 20km radius will surely be further away (on the road) than the first one you found, so you're not interested in them.
You can then use MongoDB spatial index to get all the cabs in 20km radius and then you can find among them which one has the minimum distance.
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.