If I store longitude and latitude as numeric values in 2 columns, can I get the average values of them with in a time bucket? and locf(last observation carry forward) value too? Will that average geo spatial value be accurate as it should not be just the mean value for co-ordinates?
What are the available functions for gps coordinates in timescaleDB?
can I get the average values of them within a time bucket? and locf(last observation carry forward) value too?
Yes, take a locf function. It can also be combined with avg or any aggregation functions from Postgres.
Will that average geospatial value be accurate as it should not be just the mean value for coordinates?
You can try to preview the values in a small set as this example.
Also, almost all other Postgres extensions can be combined here. PostGIS is probably the most advanced extension for it.
Related
I have a table "ways" containing coordinates (lat/lon) values. Suppose I have a coordinate (x,y) and I want to check the closest match from the table ways. I have seen some similar questions like this: Is there a postgres CLOSEST operator?
However in my case I have 2 columns instead of 1. Is there a query to do something like this this ?
You could store the data as PostGIS 'point' type instead of coordinate values:
https://postgis.net/docs/ST_MakePoint.html
https://postgis.net/docs/ST_GeomFromText.html
This would empower you with all the PostGIS functionality such as:
https://postgis.net/docs/ST_DWithin.html
Then you could create a GiST index and use the PostGIS <-> operator to take advantage of index assisted nearest neighbor result sets. The 'nearest neighbor' functionality is pretty common. Here is a great explanation:
https://postgis.net/workshops/postgis-intro/knn.html
“KNN” stands for “K nearest neighbours”, where “K” is the number of neighbours you are looking for.
KNN is a pure index based nearest neighbour search. By walking up and down the index, the search can find the nearest candidate geometries without using any magical search radius numbers, so the technique is suitable and high performance even for very large tables with highly variable data densities.
I have been trying to covert Easting and Northing values to lat/lon using JCoord and GeoTools. Problem is I am getting different results for each library using the same Easting & Northing.
The code I am using is the code provided in the main answer and GeoTools answer provided in this question.
convert latitude and longitude to northing and easting in java?
The easting I am using is : 393339
The Northing I am using is : 806179
The coordinates Jcoord is providing are (57.14645296506957, -2.111698674790966)
The coordinates GeoTools is providing are [57.146449494619105, 2.111714868502565]
They seem to lose accuracy around the 4th digit and I'm wondering which one is right??
Thanks
Assuming that these are OS Eastings and Northings (which seems likely based on your lat/lon values) then they are accurate to 1m (as 6 figure grid references). Based on the values given by this calculator a degree of latitude is around 100 km so the 4th decimal point is roughly 10m or about the accuracy you can expect.
To get more precision out of the calculation you need to make sure of the ToWGS84 parameters being used in each calculation - for GeoTools you can query the projection to find this value, I expect JCoord has a similar operation.
Note in GeoTools the towgs parameter may vary depending on which referencing factory you are using, I believe that gt-epsg-hsql is more accurate than the gt-epsg-wkt.
I am using PostGis for Location based calculations in my Application. In a Table i have a column called 'location' in geography type(Point(lon lat))...Like this number of rows present in the Table.
I want to pass a point(Point(lon lat)) and check distance between this point(i passed) and location column in all rows....and if distance is less than 5 m....it will return the name of the point.How to query this.
Assuming that your srid of your data is 4326 the query you are looking for is:
SELECT the_geom FROM mytable WHERE ST_DWithin(the_geom,ST_GeomFromEWKT("srid=4326;POINT(lon lat)"), 0.0008);
Note that the units(0.0008) in ST_DWithin are in the same units of your projection, in the 4326 case they are degrees. If your projection data is in meters, you will be able to use meters.
For a production application you should use geometry types, is faster. From a stackoverflow previous question:
Short Answer: geography is a new data type that supports long range
distances measurements. If you use geography -- you don't need to
learn much about planar coordinate systems. Geography is generally
best if all you care about is measuring distances and lengths and you
have data from all over the world. Geometry datatype is an older data
type that has many functions supporting it and enjoys great support
from third party tools. Its best if you are pretty comfortable with
spatial reference systems or you are dealing with localized data where
all your data fits in a single spatial reference system (SRID), or you
need to do a lot of spatial processing. Refer to Section 8.8, “PostGIS
Function Support Matrix” to see what is currently supported and what
is not.
Great.Thank You. It works fine in database. I have following code from PHP..it returs like, Query Failed:
$locationresult=pg_query($con,"SELECT id,name FROM gps.locationnames WHERE ST_DWithin(location,ST_GeographyFromText('POINT(lon lat)'),500)") or die ('Query Failed:'.pg_last_error($con));
What is the problem here..
I am writing an application which has ca. 7000 european restaurants in the database and I want to show a list of the nearest ones to the user, for example all of them which are in a radius of 5km to the user.
I could do the search on the server but it then requires internet. Is it possible to save the data on the iPhone and query the database? I can't find any references for something like that in core data or iPhones SQLite.
Do I really need to program it myself with Pythagoras and stuff and calculate the distance to every restaurant on every query? Or is there some other way?
[update] I'd like to use it like I do already on the server (but to do it on the iPhone): SELECT * FROM restaurants WHERE ST_Distance_Sphere(geo, ST_GeomFromText(POINT(55.98767 57.12345), -1)) < 5000
I want the user to be able to find a restaurant even if she has no internet connection, for example when you're in a foreign country.
Read up on latitude and longitude calculations. Latitude an longitude are themselves distances expressed as arcs upon a spherical surface. If you have a database of locations expressed by latitude and longitude, then you can perform a fetch to find only those records that fall within a few degrees latitude north and south and a few degrees longitude east and west of the users current location.
So you would end up with a predicate that would be something like (psuedo-code):
latitude >= (currentLatitude-aFewMinutesOfArc)
AND
latitude <= (currentLatitude+aFewMinutesOfArc)
AND
longitude >= (currentLongitude-aFewMinutesOfArc)
AND
longitude >= (currentLongitude+aFewMinutesOfArc)
... this would create a logical box which would return all restaurant records that fell within the box. Then if you needed to calculate the exact distances you would only have to perform calculation on a handful of records out of the 7,000 you have.
I would recommend reading up on Location Services because it provides a lot of tools for handling location calculations.
As to whether to use plain SQL or Core Data, check out this previous answer on the subject. In brief, if you already know the C SQL api and your data is simple, large and static, then SQL is a good choice. If you can take time to learn Core Data and your data is complex and dynamic, then Core Data is the better choice regardless of the size of the data.
You could use GeoFire for iOS. It uses Firebase to store the data, but since Firebase maintains a local cache, it will still work without a network connection. It will handle both the GeoQueries as well as notifying you in realtime as items enter and leave your query.
[disclaimer: I work at Firebase]
I'm using PostgreSQL with PostGIS. All my data has already decimal lat/long attached to it (i.e. -87.34554 33.12321) but to use PostGIS I need to convert it to a certain type of SRID.
The majority of my queries are looking for data inside a certain radius.
What SRID should I use? I created already a geometry column with SRID 4269.
In this example:
link text the author is converting SRID 4269 to SRID 32661. I'm very confused about how and when to use these SRIDs. Any lite on the subject would be truly appreciated.
As long as you never intend to reproject/transform the data to another coordinate system, it doesn't technically matter what srid you use. However assuming you don't want to throw away that important metadata, and you do want to transform it, you will want to ensure your assigned srid matches the data, so postgis knows what to do when the time comes.
So why would you want to reproject from epsg:4269? The answer is because certain types of queries (such as distance) make no sense in this 'unprojected' world. Your units are in decimal degrees, and a straight measurement of x decimal degrees is a different real distance depending where in the planet you are.
In your example above, someone is using epsg:32661 as they believe it will give them better accuracy for the are they're working in. If your data is in a specific area of the globe, you can select a projection that's accurate for that area. If it spans the entire globe, you have to choose a projection that does 'ok' for your needs.
Now fortunately PostGIS has a few ways of making all this easier. For approx distances you can just use the st_distance_sphere function which, as you might guess, assumes the earth is a sphere. Or the more accurate st_distance_spheroid. Using these, you don't need to reproject and you will probably be fine for your distance queries except in edge cases. Newer versions of PostGIS also let you use geography columns
tl;dr - use st_distance_spheroid for your distance queries, store your data in geography columns, or transform it to a local projection (when storing, or on the fly, depending on your needs).
Take a look at this question: How do you know what SRID to use for a shp file?
The SRID is just a way of storing the WKT inside the database (you may have noticed that, altough you store lat/long points, the preferred storing is a long string with number and capital letters).
The SRID or EPSG can be different for the country/state/... altough there are some very common ones especially the 2 mentioned by you. If you need specific info what area uses what SRID, there is a database for handling that.
Inside your database, you have a table spatial_ref_sys that has the information on what SRID PostGIS knows about.