New answers tagged

0

I think there are some cases where you might justifiably store a point in both geography and geometry type but don't do it until you have to. I would recommend keeping things simple and choosing one or the other unless you run into actual performance issues that only this approach could solve. The drawbacks are It's icky, like storing serialised data in ...


0

Well, first off, let me say if you are looking for a single, official, industry standard geodata model that works perfectly for all addresses across the globe, good luck and let us all know if you find one. However, that said, at least for the USA, there are some applicable geodata models for addressing data that may work as a good starting point for you. ...


0

PostGIS 2.2.0 includes the "address_standardizer" extension, which is derived from/similar to the PAGC address parser. The gazetter-and-rules approach to parsing may work better for you. I deal with property data, which in the case of undeveloped lots, may not have street numbers or otherwise "odd" addresses. You could (using the address_standardizer_data_us ...


2

Best explained from Microsoft in Spatial Data Types Overview: Measurements in spatial data types In the planar, or flat-earth, system, measurements of distances and areas are given in the same unit of measurement as coordinates. Using the geometry data type, the distance between (2, 2) and (5, 6) is 5 units, regardless of the units used. In the ...


1

I'll speculate that what the GeoDjango docs are trying to say is that if you have geographic (lat/lon) data, and you want to perform range queries on that data (like ST_DWithin) in meters rather than units of degrees, then you are better served by using the geography type, which uses meters natively. The geography distance calculations themselves (ie ...


5

Distance calculations that assume shortest distance on the Earth will always be faster than geometry because geometry can be in any projection, and there's no way generally to know that the shortest path in that projection is the 'shortest path' and so you need to go to ellipsoid calcs and potentially insert more vertices for the curvature from the source to ...


0

Your GeoJSON is not valid, remove the {'geojson': "[]"} wrapper. Not sure if that is the cause of your issue, but try with this GeoJSON instead, and see if that solves it: {"type": "FeatureCollection", "features": [{"type": "Feature", "geometry": {"type": "Point", "coordinates": [74.886779, 33.571307]}, "properties": {"rastvalues": 9, "id": 1, "species": ...


0

Maybe you can achieve this if you use Django 1.9, where you can use the new geographic database functions api. If you buffer the reference point, then annotate the service areas with the distance to the buffer, and finally filter that distance against the radius. I am not sure if annotations can be used with F expressions, but if they do, the following ...


0

from django.contrib.gis.geos import Point from django.contrib.gis.measure import Distance lat = 52.5 lng = 1.0 radius = 10 point = Point(lng, lat) Place.objects.filter(location__distance_lt=(point, Distance(km=radius)))


0

Something like this will do what you want: import ast from django.contrib.gis.geos import GeometryCollection, GEOSGeometry def make_geometrycollection_from_featurecollection(feature_collection): geoms = [] features = ast.literal_eval(feature_collection) for feature in features['features']: feature_geom = feature['geometry'] ...


1

In v3.6.0 constructor: new ol.tilegrid.XYZ(...) has been replace by static function: ol.tilegrid.createXYZ(...) See ol3 upgrade notes.


1

It's for this purpose PostGIS exists... > Don't read "all the latitudes and longitudes" just use the PostGIS geometry/geography. With PostGIS, you just need to find all points within your polygon (created from a buffer around your point). If you use spatial index, you will never have to make calculation for every points just the ones within the bounding box ...



Top 50 recent answers are included