I have groups of 10 to 700 longitude and latitude points around a city or region.
I would like to create a polygon or "blob" to cover area defined by these points.
I Could pre-process points on our server to save time.
has anyone done anything like this or seen any useful tools?
In order to find the polygon you talk about you need the compute the convex hull of your points. There are plenty of algorithms available. Here you can find one in PHP.
Related
I have a table containing geometrics points (called [Polygon_Centre]) and distances (called [Desired_Radius]). Anybody know which Snowflake function I could use to create polygon circles from this?
I'm trying to achieve a similar result to the Trade Area tool in Alteryx if anybody is familiar with that.
I was hoping for something like the following (which doesn't work):
ST_MAKEPOLYGON('Circle', [Polygon_Centre], [Desired_Radius])
Does anybody know how to create a circle polygon from a given centre point and radius in Snowflake?
Thanks everybody. I've found and used the following solution:
Calculate 120 points around the circle mathematically
Turn this into an ordered list with ST_COLLECT() (the order is critical and the start and end must match)
Use ST_MAKELINE() to turn these points into a line
Create the circle with ST_MAKEPOLYGON().
I have a list of longitudes and latitudes (each refers to a postcode),
as an example in the form of {"1111" : [-37.01, 144.8], ...} (A)
I have another location B [-48.432, 124.432]
I want to find if there are any longitude and latitude within a certain distance from the location b (5000 meters, 10000 meters, ...) that has an associated postcode.
Any thoughts?
Geodesy package can help a little in finding long and lat, but could not figure out the way for searching A
You are looking for geo-query. You can use firebase firestore or realtime database to accommodate this need without the requirement of many efforts. Geoflutterfire and flutter_geofire are the two libraries which come with the support of what you're looking for.
My question is probably a duplicate, but all the answers I have seen so far do not satisfy me or still leaves me in doubt.
I have a web application that uses Google Maps API to draw and save shapes (circles and polygons) in a SQL Server DB with the geometry data type (where I save lat/long coordinates) and an SRID = 4326.
My objective is to later on, determine if a point is contained in the area of those circles/polygons thanks to SQL function geometry::ST_Intersects().
I have been told so far that my method wouldn't work because I am using geometry instead of geography. But to my surprise... after checking with a few tests, it works perfectly well with geometry and I am not able to understand why or how?
Could somebody explain to me why the geometry type works well with operations on lat/long whereas geography would be more suited?
I post as an answer because as comment is too long
geometry works well to the extent that your intersections are approximable to flat intersections.
the difference between geometry and geography consists in the fact that the former works by hypothesizing to work on plane surfaces the second on spherical surfaces. in the case in which the polygons in question are related to small areas in the order of a few thousand meters geometry works very well. the difference between measured distance by imagining that the points lie on a plane or that the points lie on the earth's sphere is so small as to be negligible. Unlike the question if the points are a few hundred kilometers in this case the distance measured in the plane or on the sphere is very different and proportionally is also the result of the intersection between these areas
I have a spatial software, In a database I have for each street in several cities, the lat/long of each street. And every street belongs to a zone. I'm trying to get polygons for each zone, and to do this, I need an algorithm that give me as result the smallest polygon that covers a number of points. Very similar to convex hull. convex hull is useless because it resolved it like this:
And, what I need is this:
I think I have the answer, Concave hull algorithm.
There is a working npm module for calculating concave hull here: https://www.npmjs.com/package/hull.js
I use it. It's written in javascript and you can use it on server with Node.js.
I've recently start working on a personal project involving geo locations, maps (Google Maps V3) etc.
The project is developed in Python and is intended to run on Google App Engine.
I've learned that in order to find markers/position close to a position one can use to geohash algorithm (which is pretty cool).
What I don't understand is this: lets say I have all my locations in the data store (along with a latitude, longitude and a geohash (with high precision) of each location.)
I know that I should use the prefix of the geohash (to match locations within), but how do I calculate a geohash of a bounding box? Considering the bounding box is made up of two points, North-East and South-West, I do not understand how to go about doing this..
In order for me to querying which locations should be returned for the currently visible bounding box, I need the geohash of the visible/viewable bounding box - Now I know I can geohash the center location on the viewable map, but I do not know how many letters to cut off (to reduce precision) to achieve 'a fit' to the actual bounding box. (Or maybe that isn't the way...?)
What do you do when the bounding box container to geohashes? (like in the middle of the viewable area it splits between 'dqcjr0' and 'dqcjqb')
Also, lets assume I have a 5 letter geohash, how can I convert that back into a viewable bounding box? or in other words, how do I know what is 'included' the hash, and what is in adjacent hashes?
Thanks in advance for your help,
Ken.
I used geohash with google app engine data types ie db.GeoPt a lot and I used to keep a geohash which I found was inferior to combine the db.GeoPt with the very good but a bit slow library called geomodel Geomodel can do bounding-box and radius mappings and I suggest that you try with the bounding-box since it is not as expensive as the radius. I can perform a bounding-box query like this:
articles = Article.bounding_box_fetch(Article.all().filter('modified >',
timeline).filter('published =',
True).filter('modified <=',
bookmark).order('-modified'),
bounds,
max_results=PAGESIZE + 1)
So even if I stored geohash for every article, using geomodel was much better in my case. Maybe you already evaluated geomodel and found that it didn't suit your purpose and that you absolutely must use geohashes I suggest that we agree on a common library for the geohash so that our coordinates hash to the same value. I do keep a version of the geohash library I used somewhere but it is probably outdated and the recent articles about geospatial queries also metion geomodel, so if you didn't look at geomodel yet, I really propose you look at the geomodel library to perform your geospatial queries.
Ken
You may want to update your question stating whether or not you're using django / django-nonrel?
I'm just about to try this (currently archived) port of Geomodel to django:
https://bitbucket.org/scotch/django-geomodel/
Kyle suggests that the upcoming Google "full text search" would replace his Geomodel implmentation. Nonetheless, I need it working within the next few days.
(My current conversation re: this topic:
https://groups.google.com/forum/#!topic/django-non-relational/WCxFjkUzw18
)
Jon