Tag Info

New answers tagged

1

Implemented for Javascript: var r = 100/111300 // = 100 meters , y0 = original_lat , x0 = original_lng , u = Math.random() , v = Math.random() , w = r * Math.sqrt(u) , t = 2 * Math.PI * v , x = w * Math.cos(t) , y1 = w * Math.sin(t) , x1 = x / Math.cos(y0) newY = y0 + y1 newX = x0 + x1


0

As it turned out, the problem was not different algorithms calculating different distance results, but simply a problem in the C++ source code. There is a related question on Stackoverflow (“How to register a Boost.Geometry distance strategy for OGRPoint and OGRLineString?”), as well as a thread on the Boost.Geometry mailing list I created. The root cause ...


0

So you what you want to do is the direct problem, I'd do all your calculations in your projected system or even better, transform it to geodetic coordinates and resolve what is called the direct, or forward, problem and then simply get your new point in 900913. It all depends then on source projected coordinates and the accuracy you are looking for. For ...


0

For this I would project first into a Projected Coordinate System that uses units of meters. Then if you have an ArcInfo/Advanced level license use the Point Distance tool: Determines the distances from input point features to all points in the near features within a specified search radius. Alternatively, look at Performing Point Distance analysis ...


0

here's the page that link to lat/long calculations Lat/long calculations also this page Lat/long calculations there's a code + calculator


1

It looks fine and the distance is always measured in the units the SRID used defines. For 4326 that would be in angular units. Unless you use geographies like you found out, that is. Read more in the official docs here. Why 100 km is needed for Chicago is up to you and your data. It doesn't sound that much for a huge city and in fact if I check Wikipedia, ...


1

If you want to get the distance between two sets of lat/lon, 4326, points, then you can use ST_Distance_Sphere or for more accuracy, ST_Distance_Spheroid. If your fence table is in 900913, then use, ST_Transform to convert, so that both sets of points are in a common SRID. SELECT ST_Distance_Sphere( (select ST_Transform("Fence", 4326) FROM ...


0

Using the following code I can get an answer of 38355.3256m (which is probably close enough) - I imagine that with a more careful choice of central point a more "accurate" result might be obtained. Geometry g1 = reader.read("LINESTRING(13.45 52.47,13.46 52.48)"); Geometry g2 = reader.read("LINESTRING(13.00 52.00,13.1 52.2)"); ...


0

This is likely a spatial projection issue. From the GeoDjango (Django) documentation: Distance calculations with spatial data is tricky because, unfortunately, the Earth is not flat. Some distance queries with fields in a geographic coordinate system may have to be expressed differently because of limitations in PostGIS. Please see the Selecting an SRID ...


3

There's probably several methods to achieve this but I will just mention a couple. The first requires several steps. I've created a couple of simple layers with a point layer (1 feature) and a polygon layer (3 features): Use the Polygons to lines tool, I just seach the Processing Toolbox and use all tools from there: Then use Convert lines to points ...


6

The following is a rough outline of what you might do. I won't include a great deal of detail, you can research further using these terms and/or ask new more specific questions. Note: you will need to careful of coordinate systems. Firstly that they are the same for your datasets, and second that they use metric (metres) horizontal units (not actually ...


0

As alluded to by @BillW, the distance you are getting is in the units of the CRS you are using. The units of EPSG 4326 are degrees. That is, the distance (0.00003) is in degrees. If you want a distance in metres, use a CRS in metres (like UTM, or perhaps a state plane since it appears you're in the USA). Convert to miles later, if you have to.


1

It is not at all clear what methodology they used to produce this map, but absent such an explanation, I would assume that "the population center" just means the spatial centroid of the census tract; that is, that the entire tract population is assumed to be at the tract centroid and that census tracts are coded (colored) based on distance from tract ...


0

This is a simplistic example of using googles driving directions.



Top 50 recent answers are included