Area in KM from Polygon of coordinates

Area in KM from Polygon of coordinates

We are searching data for your request:

Forums and discussions:
Manuals and reference books:
Data from registers:
Wait the end of the search in all databases.
Upon completion, a link will appear to access the found materials.

I have polygons from coordinates in (python shapely) that looks like this

POLYGON ((24.8085317 46.8512821, 24.7986952 46.8574619, 24.8088238 46.8664741, 24.8155239 46.8576335, 24.8085317 46.8512821))

I would like to calculate the area of this polygon in km^2. What would be the best way to do this in Python?

It wasn't readily apparent to me how to use @sgillies answer, so here is a more verbose version:

import pyproj import shapely import shapely.ops as ops from shapely.geometry.polygon import Polygon from functools import partial geom = Polygon([(0, 0), (0, 10), (10, 10), (10, 0), (0, 0)]) geom_area = ops.transform( partial( pyproj.transform, pyproj.Proj(init='EPSG:4326'), pyproj.Proj( proj="aea", lat1=geom.bounds[1], lat2=geom.bounds[3])), geom) # Print the area in m^2 print geom_area.area

It looks like your coordinates are longitude and latitude, yes? Use Shapely's shapely.ops.transform function to transform the polygon to projected equal area coordinates and then take the area.

python import pyproj from functools import partial geom_aea = transform( partial( pyproj.transform, pyproj.Proj(init='EPSG:4326'), pyproj.Proj( proj="aea", lat1=geom.bounds[1], lat2=geom.bounds[3])), geom) print(geom_aea.area) # Output in m^2: 1083461.9234313113

The above answers seem to be correct, EXCEPT that at some point recently, the lat1 and lat2 parameters in the pyproj code were renamed with underscores: lat_1 and lat_2 (see I don't have enough rep to comment, so I'm making a new answer (sorry not sorry)

import pyproj import shapely import shapely.ops as ops from shapely.geometry.polygon import Polygon from functools import partial geom = Polygon([(0, 0), (0, 10), (10, 10), (10, 0), (0, 0)]) geom_area = ops.transform( partial( pyproj.transform, pyproj.Proj(init='EPSG:4326'), pyproj.Proj( proj="aea", lat_1=geom.bounds[1], lat_2=geom.bounds[3])), geom) # Print the area in m^2 print geom_area.area

Calculate a geodesic area, which is very accurate and only requires an ellipsoid (not a projection). This can be done with pyproj 2.3.0 or later.

from pyproj import Geod from shapely import wkt # specify a named ellipsoid geod = Geod(ellps="WGS84") poly = wkt.loads(" POLYGON ((24.8085317 46.8512821, 24.7986952 46.8574619, 24.8088238 46.8664741, 24.8155239 46.8576335, 24.8085317 46.8512821))") area = abs(geod.geometry_area_perimeter(poly)[0]) print('# Geodesic area: {:12.3f} m^2'.format(area)) print('# {:12.3f} km^2'.format(area/1e6)) # Geodesic area: 1083466.869 m^2 # 1.083 km^2

abs()is used to return only positive areas. A negative area may be returned depending on the winding direction of the polygon.

I've stumbled across "area" which seems simpler to use:

For example:

from area import area obj = {'type':'Polygon','coordinates':[[[24.8085317,46.8512821], [24.7986952,46.8574619], [24.8088238,46.8664741], [24.8155239,46.8576335], [24.8085317,46.8512821]]]} area_m2 = area(obj) area_km2 = area_m2 / 1e+6 print ('area m2:' + str(area_m2)) print ('area km2:' + str(area_km2))

… returns:

area m2:1082979.880942425

area km2:1.082979880942425

I've found that the projected option is a bit too slow for my use so I did some digging and found a javascript lib from Mapbox called cheap-ruler. The "cheap" in the name is intended to imply that this algorithm isn't intended to return the right answer, but simply a good enough one.

Below is my copy and paste port of the area function to work with a shapely geom. My port doesn't remove area for holes, but it could be updated to do so.

import math def area(geom): ## Setup from: ## RE = 6378.137 RAD = math.pi / 180 FE = 1 / 298.257223563 E2 = FE * (2 - FE) lat = geom.centroid.y m = RAD * RE * 1000 coslat = math.cos(lat * RAD); w2 = 1 / (1 - E2 * (1 - coslat * coslat)) w = math.sqrt(w2) kx = m * w * coslat ky = m * w * w2 * (1 - E2) ## Area calc from: ## ring = geom.exterior.coords sumVal = 0 j = 0 l = len(ring) k = l - 1 while j < l: sumVal += wrap(ring[j][0] - ring[k][0]) * (ring[j][1] + ring[k][1]) k = j j += 1 return (abs(sumVal) / 2) * kx * ky; def wrap(deg): while deg < -180: deg += 360 while deg > 180: deg -= 360 return deg

System refinement for content based satellite image retrieval

We are witnessing a large increase in satellite generated data especially in the form of images. Hence intelligent processing of the huge amount of data received by dozens of earth observing satellites, with specific satellite image oriented approaches, presents itself as a pressing need. Content based satellite image retrieval (CBSIR) approaches have mainly been driven so far by approaches dealing with traditional images. In this paper we introduce a novel approach that refines image retrieval process using the unique properties to satellite images. Our approach uses a Query by polygon (QBP) paradigm for the content of interest instead of using the more conventional rectangular query by image approach. First, we extract features from the satellite images using multiple tiling sizes. Accordingly the system uses these multilevel features within a multilevel retrieval system that refines the retrieval process. Our multilevel refinement approach has been experimentally validated against the conventional one yielding enhanced precision and recall rates.

Welcome to VegMachine ®

VegMachine is an online tool that uses satellite imagery to summarise decades of change in Australia’s grazing lands. It’s simple to operate, easy to understand, and free to use.

  • generate comprehensive ground cover monitoring reports
  • measure land cover change or estimate soil erosion rates
  • view satellite image land cover products
  • better understand the links between management, climate and cover in grazing land

To get started visit our help page. View our privacy policy here.

This project is supported by Fitzroy Basin Association Inc. through funding from the Australian Government’s Reef Programme.

Simple methods¶

Now we have our GeoDataFrame and can start working with its geometry.

Since we have only one geometry column read from the file, it is automatically seen as the active geometry and methods used on GeoDataFrame will be applied to the "geometry" column.

Measuring area¶

To measure the area of each polygon (or MultiPolygon in this specific case), we can use GeoDataFrame.area attribute, which returns a pandas.Series . Note that GeoDataFrame.area is just GeoSeries.area applied to an active geometry column.

But first, we set the names of boroughs as an index, to make the results easier to read.


The input point, line, or polygon features to be buffered.

The feature class containing the output buffers.

The distance around the input features that will be buffered. Distances can be provided as either a value representing a linear distance or as a field from the input features that contains the distance to buffer each feature.

If linear units are not specified or are entered as Unknown, the linear unit of the input features' spatial reference is used.

When specifying a distance in scripting, if the desired linear unit has two words, like Decimal Degrees, combine the two words into one (for example, '20 DecimalDegrees').

The side(s) of the input features that will be buffered.

  • FULL — For line input features, buffers will be generated on both sides of the line. For polygon input features, buffers will be generated around the polygon and will contain and overlap the area of the input features. For point input features, buffers will be generated around the point. This is the default.
  • LEFT — For line input features, buffers will be generated on the topological left of the line. This option is not valid for polygon input features.
  • RIGHT — For line input features, buffers will be generated on the topological right of the line. This option is not valid for polygon input features.
  • OUTSIDE_ONLY — For polygon input features, buffers will be generated only outside the input polygon (the area inside the input polygon will be erased from the output buffer). This option is not valid for line input features.

This optional parameter is not available with a Basic or Standard license.

The shape of the buffer at the end of line input features. This parameter is not valid for polygon input features.

  • ROUND — The ends of the buffer will be round, in the shape of a half circle. This is the default.
  • FLAT — The ends of the buffer will be flat, or squared, and will end at the endpoint of the input line feature.

This optional parameter is not available with a Basic or Standard license.

Specifies the dissolve to be performed to remove buffer overlap.

  • NONE — An individual buffer for each feature is maintained, regardless of overlap. This is the default.
  • ALL — All buffers are dissolved together into a single feature, removing any overlap.
  • LIST — Any buffers sharing attribute values in the listed fields (carried over from the input features) are dissolved.

The list of field(s) from the input features on which to dissolve the output buffers. Any buffers sharing attribute values in the listed fields (carried over from the input features) are dissolved.


Based on a quantitative comparison of mountain definitions that include ruggedness, elevation, and climate, we argue that the combination of ruggedness and climate is the most pertinent approach for biological questions, including biodiversity assessments and forest inventories. The mountain inventory we then provide based on this approach facilitates the access to regionalized mountain statistics.

Global mountain statistics

Both GIS-based approaches (WCMC and GMBA) rely on specific assumptions and serve as ‘conventions’ that can help in establishing standardized protocols. The GMBA 200 m ruggedness threshold across the 9 neighbouring 30″ grid points for instance resulted from test runs, exploring the smallest elevation amplitude that still captures what might be considered a mountain rather than a hill. Tests runs for the Alps revealed that a 200 m ruggedness threshold causes a clear distinction between the Alps and the forelands, with almost all narrow, low elevation valleys within the Alps still belonging to the mountain category (because the valley floors are commonly <2 km wide). In Switzerland in general, the 200 m threshold allows for the Swiss plateau or Swiss midlands, with all major cities and cropland, to fall outside the GMBA mountain definition. By the WCMC criteria, this same area largely falls into the mountain category, as do all plateaus at high elevation (e.g., Tibetan Plateau, yellow area in Fig. 2, bottom left), whereas most coastal mountains are disregarded (e.g., Norway, red area in Fig. 2, top right). Hence, the major part of the discrepancy between the WCMC and GMBA approach is located far below 1000 m asl in the undulating, low elevation hill country, outside the mountains, with a peak near 300 m asl, and does presumably not result from the inclusion or exclusion of the high plateaus (the small hump near 5000 m asl in Fig. 3), because the really flat parts of those plateaus are quite small. These distinctions are important in view of the human population statistics, as many people considered to be ‘mountain people’ in the WCMC approach (FAO 2015) are living on land that causes a divergence in the WCMC and the GMBA estimates at very low elevation (see examples in Fig. 2).

It is worth noting that a very large fraction (the majority) of the world’s mountains falls in a low elevation category by all three mountain concepts, with comparatively high temperatures, particularly at low latitude. Furthermore, neither of the applied definitions uses low temperatures alone as a criterion for mountains, thereby preventing the attribution of vast Arctic and Antarctic lowland terrain to mountainous areas.

Mountain polygons

In contrast to a grid-based assessment of all terrestrial area, mountain polygons cannot provide an exhaustive representation of mountainous terrain. Mountain polygons are arbitrary shapes that inevitably include some low elevation or non-mountainous terrain and fail to account for certain (including isolated) mountains that would be recognized by a grid-based statistical procedure. Hence, only the mountainous terrain within polygons should be used to calculate mountain statistics, and not the total polygon area. With a coverage of approximately 13.8 Mio km 2 , the polygons capture most of the 16.5 Mio km 2 of global mountain terrain estimated with the GMBA approach. This suggests that individual polygons and our inventory as a whole capture the existing mountain terrain sufficiently well for locating mountains and mountain ranges and for comparative purposes. The missing 2.7 Mio km 2 mostly consists of mountain terrain that is too scattered to be included in discrete polygons. Many of the missing, smaller mountains would probably not appear as distinct mountains on a physical world map and may also remain unnamed even though the absence of name is not always a matter of size. Larger rugged areas, for which no name could be found in atlases or online, were identified with codes for the purpose of this work. The largest discrepancies between GMBA and POLY were observed in Africa and Australia and may partly be attributed to the greater difficulties of delineating mountain terrain in areas where rugged terrain is more scattered or less conspicuous such as on the old Gondwana land shields.

The 1003 polygons of this first inventory are neither perfect nor comprehensive and refinements, including the use of a higher resolution Digital Elevation Model, will be needed in subsequent releases to achieve better coverage and higher accuracy. The three major criticisms to this first release are (1) the absence of some specific mountains or ranges, (2) the lumping of certain mountains, and (3) the inclusion of non-rugged terrain in individual polygons. The latter is intrinsic to the polygon delineation concept but does not affect the area of mountain terrain within polygons, which is strictly defined by GIS-based algorithms. The second criticism on lumping individual mountains is the most challenging to address, as the arguments for and against doing so can be numerous and controversial. User feedback will help improve this first version of the GMBA mountain inventory to possibly overcome the shortcomings that might result from the decisions we made in the delineation process.

Climatological stratification of mountain terrain

Since from a climatic point of view, it makes a considerable difference whether a mountain defined by ruggedness is in the Arctic, the temperate zone, or near the equator, a climatic stratification of land area is essential to identify ecologically comparable land cover units across the mountains of the world. Since available climatic layers (e.g., from WORLDCLIM) can be overlaid onto mountain topography, categorizations into any climatic belt are possible. For a climatic stratification to make sense and become globally useful, it should ideally capture conditions that reflect established biogeographic categories such as terrain above (alpine) and below (montane) the climatic treeline. As shown previously, the potential high-elevation tree limit is found at a globally common isotherm for the growing season (Körner 2012 Körner and Paulsen 2004 Körner et al. 2011) and, therefore, offers a bioclimatic reference, against which all other climatic belts in mountains can be positioned. Measures of temperature that include the dormant period in extratropical mountains, such as mean annual temperature (Jobbágy and Jackson 2000) or the mean temperature for the warmest month only—the often quoted 10 °C July isotherm for the northern temperate zone (Köppen 1919 Jarvis et al. 1989 Ohsawa 1990 Malyshev 1993), may fit either by chance or for certain latitudes or regions, but they do not capture global patterns (Hardy et al. 1998 Körner 1998).

Geophysical mountain statistics thus need to address two different issues: the first one is related to the structure of the elevated land surface, its ruggedness, and its exposure to the forces of gravity (the topographic nature of mountains), and the other one is related to the climatic life conditions (the climatic nature of mountains). At a given elevation, topography is independent of latitude, whereas climate is not. Topographically similar mountain terrain can be found in the Arctic and at the equator. Hence, a mountain concept that can be used for global comparisons must combine topography with a coherent climatological characterization as either one alone is insufficient and absolute elevation (m asl) alone is not ecologically meaningful either. Yet, there is a caveat, in that climatic data obtained from weather stations (2 m air temperature) do not represent the actual climatic conditions experienced within low stature vegetation and by soil biota (Scherrer and Körner 2011). Hence, assessing the actual life conditions of small plants, ground dwelling animals, and soil microbes will continue to require ground truth data.

Human populations in mountains

Given the significance of land use for biodiversity, it is interesting to estimate to which extent mountains are inhabited by humans. Using the combined ruggedness and climatic stratification of the world’s mountains (sensu GMBA), we estimated human population densities in specific climatic belts within polygons and globally. Among the various observations we made, three were particularly surprising: (1) the comparatively high human population density in mountainous areas, given that much of the rugged terrain is very steep, very high, forested, or represents dangerous terrain (2) the 53 million inhabitants in the relatively small mountain areas within polygons of Africa, indicating an over-proportional significance of mountain livelihoods and (3) the approximately 23 million people inhabiting mountains in Europe, which indicate that the immediate forelands and the interior valleys are densely populated. Taken together, the human population data clearly evidence that by far the majority of ‘mountain people’ are inhabiting low elevation rugged terrain in tropical and warm temperate regions, and face challenges associated with steep slopes rather than with low temperatures. Above the inhabited areas, land use might nevertheless be very intense.

Because the fraction of mountainous land differs between mountain definitions, human population estimates for specific regions differ as well. Accordingly, the values we present differ substantially from estimates provided elsewhere (e.g., EEA report 2010 FAO 2015), which are based on the WCMC definition of mountains or variants of it. However, based on the estimates we obtain for human populations in Swiss mountains for example, we believe that the GMBA definition of mountains leads to meaningful results. Additional variation in the reported continent-based estimates may come from methodological assumptions specific to our calculations and from the division of the world we apply, which differs from the United Nations Statistics Division “M.49” standard used in FAO 2015 primarily, in that Australia is kept separate from Oceania, and Greenland is kept separate from North America.

In our opinion, the availability of human population data and the resulting climate co-defined livelihood statistics are a goldmine for the mountain biology and ecology community. These data open up the avenue for many interesting socio-ecological research questions, including the estimation of ecologically important regional demands for natural resources such as fire wood or grazing land, of current and future pressure on medicinal plants, and of pressure from hunting and tourism. Known caveats associated with these data include the fact that (1) the global statistics ignore political boundaries, which means that a regional match with national inventory data is not possible, (2) the 2.5′ grid (4.6 × 4.6 km at the equator) is quite coarse, which means that any rugged 2.5′ pixel can, and often does, include non-rugged land fractions suitable for settlement (3) the data cannot reliably capture land use intensity, particularly pastoralism, which is not necessarily directly correlated with population densities and (4) the data are likely imprecise in specific locations when none of the data sources is accurate. Specific drawbacks of the light-emission information used in generating the LandScan include their low reliability in certain locations such as high-elevation mountain resorts, where light emissions are often disproportionally high compared to the number of inhabitants. These caveats remain despite regional adjustments but the data still allow the estimation of potential human impact on mountain ecosystems and the identification of regions of high and low risk for biodiversity losses.

Line layers

Map Admin Line (MapAdminLine)

This line layer represents administrative boundary lines.

Map Admin Link (MapAdminLink)

This line layer represents all linear administrative boundaries on a per-link basis.

This line layer represents highways.

Map Major Roads (MapMajorRoads)

This line layer represents major roads.

Map Motorways (MapMotorways)

This line layer represents motorways.

Map Railroad Link (MapRailroadLink)

This line layer represents railroad features.

Map Water Link (MapWaterLink)

This line layer represents water features.

One Way Arrows (OneWayArrows)

This line layer represents one-way arrows to show direction of travel on one-way streets.

Turn Restrictions (RestrictedTurns)

This line layer represents restrictions to the route network that are defined based on two or more links.

Streets for network (Routing_Streets)

This line layer represents streets for network routing. This dataset is licensed and requires a license file for access.

This line layer contains Sign Text information for roads for network routing.

This line layer represents streets, highways, roads, ramps, and ferries. This dataset includes all navigable links, with their attribution relevant for route calculation and route guidance. In addition, this road network includes transport trucking restrictions and preferred routes, as well as historical traffic data and pedestrian routes. This dataset is licensed and requires a license file for access.

Cartographic Streets (Streetscarto)

This line layer contains linear features that represent cartographic street features. This dataset is licensed and requires a license file for access.

1.2 Object-Relational Model

Spatial supports the object-relational model for representing geometries. The object-relational model uses a table with a single column of SDO_GEOMETRY and a single row per geometry instance. The object-relational model corresponds to a "SQL with Geometry Types" implementation of spatial feature tables in the Open GIS ODBC/SQL specification for geospatial features.

The benefits provided by the object-relational model include:

Support for many geometry types, including arcs, circles, compound polygons, compound line strings, and optimized rectangles

Ease of use in creating and maintaining indexes and in performing spatial queries

Index maintenance by the Oracle database

Geometries modeled in a single row and single column

Area in KM from Polygon of coordinates - Geographic Information Systems

Showing 23 changed files with 410 additions and 50 deletions.

@@ -0,0 +1,8 @@
namespace Geo
internal class Constants
public const double NauticalMile = 1852d
public const double EarthMeanRadius = 6371008.7714d
@@ -0,0 +1,23 @@
using Geo . Interfaces
using Geo . Reference

namespace Geo
public class GeoContext
private static GeoContext _current

public static GeoContext Current

public GeoContext ()
GeodeticCalculator = SpheroidCalculator . Wgs84 ()

public IGeodeticCalculator GeodeticCalculator
@@ -0,0 +1,18 @@
using System . Collections . Generic
using Geo . Geometries
using Geo . Measure
using Geo . Reference

namespace Geo . Interfaces
public interface IGeodeticCalculator
GeodeticLine CalculateOrthodromicLine ( ILatLng point , double heading , double distance )
GeodeticLine CalculateOrthodromicLine ( ILatLng point1 , ILatLng point2 )
GeodeticLine CalculateLoxodromicLine ( ILatLng point1 , ILatLng point2 )
Area CalculateArea ( IEnumerable < Coordinate > coordinates )
Area CalculateArea ( ILatLng point , double radius )
double CalculateMeridionalParts ( double latitude )
double CalculateMeridionalDistance ( double latitude )
@@ -1,9 +1,11 @@
using Geo . Geometries
using Geo . Measure

namespace Geo . Interfaces
public interface IGeometry : IRavenIndexable
Envelope GetBounds ()
Area GetArea ()

Oops, something went wrong. Retry

0 comments on commit 52fbdc7

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

1.5.5 Tolerance

Tolerance is used to associate a level of precision with spatial data. Tolerance reflects the distance that two points can be apart and still be considered the same (for example, to accommodate rounding errors). The tolerance value must be a positive number greater than zero. The significance of the value depends on whether or not the spatial data is associated with a geodetic coordinate system. (Geodetic and other types of coordinate systems are described in Coordinate System.)

For geodetic data (such as data identified by longitude and latitude coordinates), the tolerance value is a number of meters. For example, a tolerance value of 100 indicates a tolerance of 100 meters. The tolerance value for geodetic data must be 0.05 (5 centimeters) or greater. Spatial and Graph uses 0.05 as the tolerance value for geodetic data if you specify a smaller value with the following functions: SDO_GEOM.RELATE, SDO_GEOM.SDO_DIFFERENCE, SDO_GEOM.SDO_INTERSECTION, SDO_GEOM.SDO_UNION, and SDO_GEOM.SDO_XOR however, the geometries must be valid at the 0.05 tolerance.

For non-geodetic data, the tolerance value is a number of the units that are associated with the coordinate system associated with the data. For example, if the unit of measurement is miles, a tolerance value of 0.005 indicates a tolerance of 0.005 (that is, 1/200) mile (approximately 26 feet or 7.9 meters), and a tolerance value of 2 indicates a tolerance of 2 miles.

In both cases, the smaller the tolerance value, the more precision is to be associated with the data.

For geodetic and projected data, the tolerance value should be less than 10. In addition, ensure that geometries are valid at the specified tolerance.

For geometries that have 16 or more digits of precision, Spatial and Graph boolean operations (such as SDO_GEOM.SDO_UNION and SDO_GEOM.SDO_INTERSECTION) and the SDO_GEOM.RELATE function might produce inconsistent results due to the loss of precision in floating point arithmetic. The number of digits of precision is calculated as in the following example: if the tolerance is set to 0.0000000005 and the coordinates have 6 digits to the left of decimal (for example, 123456.4321), the precision is 10 + 6 digits (16). In such cases, it is better to use a larger tolerance value (fewer leading zeros after the decimal) to get consistent results using spatial operations.

Floating point operations tend to lose precision when the number of digits used in the computation is more than 15, so make sure the number of digits specified for computations is less than 15. For example, if the number is 123456.789 and the tolerance is 10E-10, then this effectively means 16 (10+6) digits of precision, which is more than the recommended 15.

A tolerance value is specified in two cases:

In the geometry metadata definition for a layer (see Tolerance in the Geometry Metadata for a Layer)

As an input parameter to certain functions (see Tolerance as an Input Parameter)

For additional information about tolerance with linear referencing system (LRS) data, see Tolerance Values with LRS Functions. Tolerance in the Geometry Metadata for a Layer

The dimensional information for a layer includes a tolerance value. Specifically, the DIMINFO column (described in DIMINFO) of the xxx_SDO_GEOM_METADATA views includes an SDO_TOLERANCE value for each dimension, and the value should be the same for each dimension.

If a function accepts an optional tolerance parameter and this parameter is null or not specified, the SDO_TOLERANCE value of the layer is used. Using the non-geodetic data from the example in Simple Example: Inserting_ Indexing_ and Querying Spatial Data, the actual distance between geometries cola_b and cola_d is 0.846049894. If a query uses the SDO_GEOM.SDO_DISTANCE function to return the distance between cola_b and cola_d and does not specify a tolerance parameter value, the result depends on the SDO_TOLERANCE value of the layer. For example:

If the SDO_TOLERANCE value of the layer is 0.005, this query returns .846049894.

If the SDO_TOLERANCE value of the layer is 0.5, this query returns 0.

The zero result occurs because Spatial and Graph first constructs an imaginary buffer of the tolerance value (0.5) around each geometry to be considered, and the buffers around cola_b and cola_d overlap in this case. (If the two geometries being considered have different tolerance values, the higher value is used for the imaginary buffer.)

You can, therefore, take either of two approaches in selecting an SDO_TOLERANCE value for a layer:

The value can reflect the desired level of precision in queries for distances between objects. For example, if two non-geodetic geometries 0.8 units apart should be considered as separated, specify a small SDO_TOLERANCE value such as 0.05 or smaller.

The value can reflect the precision of the values associated with geometries in the layer. For example, if all geometries in a non-geodetic layer are defined using integers and if two objects 0.8 units apart should not be considered as separated, an SDO_TOLERANCE value of 0.5 is appropriate. To have greater precision in any query, you must override the default by specifying the tolerance parameter.

With non-geodetic data, the guideline to follow for most instances of the second case (precision of the values of the geometries in the layer) is: take the highest level of precision in the geometry definitions, and use .5 at the next level as the SDO_TOLERANCE value. For example, if geometries are defined using integers (as in the simplified example in Simple Example: Inserting_ Indexing_ and Querying Spatial Data), the appropriate value is 0.5 however, if geometries are defined using numbers up to four decimal positions (for example, 31.2587), the appropriate value is 0.00005.

This guideline should not be used if the geometries include any polygons that are so narrow at any point that the distance between facing sides is less than the proposed tolerance value. Be sure that the tolerance value is less than the shortest distance between any two sides in any polygon.

Moreover, if you encounter "invalid geometry" errors with inserted or updated geometries, and if the geometries are in fact valid, consider increasing the precision of the tolerance value (for example, changing 0.00005 to 0.000005). Tolerance as an Input Parameter

Many spatial functions accept a tolerance parameter, which (if specified) overrides the default tolerance value for the layer (explained in Tolerance in the Geometry Metadata for a Layer). If the distance between two points is less than or equal to the tolerance value, Spatial and Graph considers the two points to be a single point. Thus, tolerance is usually a reflection of how accurate or precise users perceive their spatial data to be.

For example, assume that you want to know which restaurants are within 5 kilometers of your house. Assume also that Maria's Pizzeria is 5.1 kilometers from your house. If the spatial data has a geodetic coordinate system and if you ask, Find all restaurants within 5 kilometers and use a tolerance of 100 (or greater, such as 500), Maria's Pizzeria will be included, because 5.1 kilometers (5100 meters) is within 100 meters of 5 kilometers (5000 meters). However, if you specify a tolerance less than 100 (such as 50), Maria's Pizzeria will not be included.

Tolerance values for spatial functions are typically very small, although the best value in each case depends on the kinds of applications that use or will use the data. See also the tolerance guidelines in Tolerance in the Geometry Metadata for a Layer, and ensure that all input geometries are valid. (Spatial functions may not work as expected if the geometry data is not valid.)

If you explicitly want to use the tolerance value from the dimensional information array for the geometry layer, and if a subprogram has separate formats with tolerance (or tol ) and dim parameters, use the format with dim . In the following example, the first statement uses the tolerance value from the dimensional information array, and the second statement specifies a numeric tolerance value (0.005):


  1. Tojall

    Interesting blog, added to rss reader

  2. Pepe

    You are not right. We will discuss it.

  3. Braoin

    Congratulations, great message

  4. Balmaran

    In it something is also to me it seems it is excellent idea. Completely with you I will agree.

  5. Jedaiah

    I apologise, that I can help nothing. I hope, to you here will help.

  6. Tyson

    I can't take part in the discussion right now - there is no free time. But I'll be free - I will definitely write what I think on this issue.

  7. Kek

    I used to think differently, thanks a lot for the info.

Write a message