search

open-contracting / standard

Documentation of the Open Contracting Data Standard (OCDS)
http://standard.open-contracting.org/
Other
138 stars 46 forks source link

Location information #26

Closed practicalparticipation closed 9 years ago

practicalparticipation commented 10 years ago

The work of Development Gateway in Nepal has focused on the importance of geo-ocation data for contracts. Whilst not often available from suppliers right now, there are clear uses cases for wanting this at the level of:

Is the current proposal that this would be an extension?

birdsarah commented 10 years ago

Yes, it's neither in the data we're looking at, nor in the use case requirements that have come up so far, so I would suggest its an extension for now.

(How would you like to store this, close it, tag it?)

practicalparticipation commented 10 years ago

I think the Nepal work does highlight there is a use case here, just not one we've captured yet - so whilst I agree it can be captured as an extension, it's one I think we should have ready for launch.

Perhaps we should put 'Working out how extensions will work' in a future sprint (you may already have this all worked out, and that just involves us writing it down somewhere), and then I could potentially look at this in September.

Can we tag as 'Extension' and 'For Beta' or something like that?

birdsarah commented 10 years ago

Documenting add-ons is handled by #50

practicalparticipation commented 9 years ago

Changing to the Release Candidate milestone as there is strong pressure from user demand side to have either:

(a) A location extension prototyped by launch

or

(b) Location elements integrated into the standard

I will do some work on a mock-up of how this could work, based on the IATI location elements and mapping for results.

practicalparticipation commented 9 years ago

Current options on location elements:

A simple lat, lng element

This could be attached to organisations, line-items and in other places in the standard. This fits with the approach in flat source data (e.g. UK contracts finder).

Incorporate elements from Geo JSON

This would let us support points, multi-points, and different Coordinate Reference Schemes.

If we limit to a sub-set of geoJson, then it should be possible to attach location to line-items and other fields without requiring a lot of extra fields in flattened versions.

However, the geoJSON schema turns out to be rather complex, particularly for coordinate reference schemes (CRS) (see https://github.com/fge/sample-json-schemas/tree/master/geojson) and it doesn't include administrative geography classifications.

Mirror the IATI Location Elements in our schema

These are available here and cover point based locations in different coordinate schemes, and administrative geography classifications.

The detailed location reach, location class fields etc. do offer substantial expressiveness, but is this needed in contracting data?

Custom lat, lng, gazeteer, precision and ADM1/2 classifications,

The Nepal country pilot of geocoding contracts introduces a series of custom fields, namely:

HXL Approach

Humanitarian Exchange Language has a detailed set of location tags, with distinct tags for ADM1 - 5.

jpmckinney commented 9 years ago

I would consider administrative region-type properties to be different from location properties. Administrative regions are a way of describing a location's parent geographies. Sometimes that's all you need, e.g. if you want to compare investment in different provinces.

For location, I'd suggest starting with a simple pair of latitude and longitude properties, where the coordinates are expressed in decimal degrees in the WGS84 (EPSG:4326) projection, which is by far the most popular and the default on the web, GeoJSON, etc.

LindseyAM commented 9 years ago

FYI we are moving forward with location in Nepal (the thinking is a list of administrative areas, the districts and subdistrict levels).

jpmckinney commented 9 years ago

FYI, CoST includes a field for this ("Project location: Briefly specify location of the project")

practicalparticipation commented 9 years ago

Does CoST have any structured data for location? Or just free text?

jpmckinney commented 9 years ago

CoST is not a technical standard, so it has no structure.

practicalparticipation commented 9 years ago

Based on conversations with Owen Scott the following points seem important for location:

(1) Latitude and longitude are generally not that useful, and are often misleading: locations can be an artefact of whatever geocoding process the publisher used, and most projects / contracts are not delivered at a point location. Rather, they are delivered in polygon spaces.

(2) Much better is to focus on administrative geography levels, and entities like cities. These are identified using gazetteers.

(3) There is an important distinction between locations that are the administrative entity identified (e.g. the contract is to run waste collection for a given district), and location that are within an administrative entity (e.g. the contract is to build three schools in a district, but there are lots of other schools in the area too).

(4) There is no single uniform global gazetteer to draw upon, and the coverage of gazetteers and the availability of open boundary and other data to go with them varies from country to country.

This leads to a suggestion that our location property in an ideal world should consist of an array of objects, with properties to represent:

In practice, allowing an array of objects does raise a slight challenge:

In this approach, a valid gazetteer might be 'ISO 3166' allowing the country of a contract to be specified via a location entry with ADM0 (Country level) and the country code. Equally, if Open Street Map is included as a gazetteer, pointers could be made to specific entities in a country where users want very detailed geocoding.

The conversion of data to lat-lng or polygon maps would then be a third-party task using lookups.

Given that addresses can be geocoded, and organisational identifiers should be possible to look-up and resolve to an organisation with an address (in theory... though not practice in many cases just yet) which can be geocoded, I'm not sure there is a strong case to include location at the organisation level.

Questions

Are we happy with a model that avoids lat,lng (through doesn't prevent them being expressed, as we could include a gazetteer appropriate to point locations) in place of administrative geography levels?

Are there cases where a publisher would want to state the location of a contract, but not at the line-item level? i.e. should location also be possible to attach at the general tender / contract level?

jpmckinney commented 9 years ago

Sure. GADM, GeoNames and FAO have pretty good coverage, and associated ontologies:

birdsarah commented 9 years ago

Having been back and forth discussing the many ways this could work, we've realized this is one for after RC. We are building a sample extension for it though to serve as a point of discussion.

AlCollier commented 9 years ago

In EU contract notices have to include NUTS code to indicate administrative region where contract is to be delivered.

practicalparticipation commented 9 years ago

@AlCollier Thanks for the pointer on this. I've logged NUTS as a possible value we will need in the location extension codelists.

myroslav commented 9 years ago

FYI, http://ec.europa.eu/internal_market/publicprocurement/e-procurement/golden-book/catalogue/practice9_en.htm explicitly lists ability to search procurement database via "the place of delivery".

mikelmaron commented 9 years ago

Hi. Was directed here from work on another extension. https://docs.google.com/document/d/1uPXFXTRXXc2zi3vo_arrWm_c_gW6KSPG5aAlD2ri5rw/edit#

Just wanted to make a drive by comment on explicit location (ala a GeoJSON chunk restricted to epsg:4326) vs flexible gazateer reference (ala IATI). Even if not immediately widely useful, I suggest future proofing, and allowing the flexibility of either or both locations.

I think this point speaks to the importance for allowing capture of detailed location

(3) There is an important distinction between locations that are the administrative entity identified (e.g. the contract is to run waste collection for a given district), and location that are within an administrative entity (e.g. the contract is to build three schools in a district, but there are lots of other schools in the area too).

In the case where the contract is to build three schools, more precise locations of those schools within the district would be extremely valuable.

jpmckinney commented 9 years ago

Links to IATI docs:

myroslav commented 9 years ago

We'd solved that with following approach:

Item has deliveryAddress (administrative address, if possible) and deliveryLocation (lat/long to make location less ambiguous).

This approach allows

  1. having only deliveryAddress and rely upon geocoding or logistics to have contract fulfilled.
  2. having only deliveryLocation and rely upon reverse geocoding to have address (for adminstrative grouping)
  3. have both with deliveryLocation overriding the deliveryAddress in logistics, and deliveryAddress overriding deliveryLocation in administrative grouping cases

This way we have human readable addresses and ability to have broad address and exact location in cases when postal address is not yet assigned.

jpmckinney commented 9 years ago

Also received feedback:

Just on location, good to have options but not too many. I like the idea of an optional combination IATI geocoder references to admin boundary (which supports OSM also), and/or a 4326 GeoJSON chunk (portable and flexible for specifying a location; important for when this kind of data becomes more available.

timgdavies commented 9 years ago

In the extensions folder I've added a second proposal for the location extensions.

The JSON schema patch can be found here, and a draft codelist can be found here.

I would welcome feedback on this proposal. Things to note:

I've not yet adding multi-language or mergeStrategy support to this draft schema, and still need to test with some live examples, but thought I would share a this point for any thoughts and comments.

myroslav commented 9 years ago

It would be great to have some examples of gazetteer and activityLocation (specifically something like point, line (road), circle, polygon) property values.

The question about activityLocation vs deliveryLocation. Can "delivery" be treated as place for service delivery? This way the same property can be used for tangible and intangible procurement items.

timgdavies commented 9 years ago

I'll work up some examples to share soon.

The issue with the term delivery I think comes in when we're using this to capture concessions type contracts as well, so I was trying to future-proof the concept.

I.e. whilst it might be natural to think of delivery covering both tangible and non-tangible places where a service is offered, delivery doesn't work so well for an oil exploration license.

Whereas, keeping 'deliveryAddress' as the physical place something should be sent to, an activity location could capture:

However, the alternative to this generalising of the property name would be to recognise a distinct 'deliveryLocation', 'licenseLocation' etc. so open to suggestions on this.

On Tue, Mar 24, 2015 at 11:04 AM, Myroslav Opyr notifications@github.com wrote:

It would be great to have some examples of gazetteer and activityLocation (specifically something like point, line (road), circle, polygon) property values.

The question about activityLocation vs deliveryLocation. Can "delivery" be treated as place for service delivery? This way the same property can be used for tangible and intangible procurement items.

— Reply to this email directly or view it on GitHub https://github.com/open-contracting/standard/issues/26#issuecomment-85452013 .

+44 (0)7834 856 303 @timdavies http://www.timdavies.org.uk

AlCollier commented 9 years ago

Hi Tim delivery will often be in the sense of service delivery; an old people's home, an area for rubbish collection, etc

-----Original Message----- From: "timgdavies" notifications@github.com Sent: ‎26/‎03/‎2015 12:38 To: "open-contracting/standard" standard@noreply.github.com Cc: "Al Collier" collier.al@gmail.com Subject: Re: [standard] Location information (#26)

I'll work up some examples to share soon.

The issue with the term delivery I think comes in when we're using this to capture concessions type contracts as well, so I was trying to future-proof the concept.

I.e. whilst it might be natural to think of delivery covering both tangible and non-tangible places where a service is offered, delivery doesn't work so well for an oil exploration license.

Whereas, keeping 'deliveryAddress' as the physical place something should be sent to, an activity location could capture:

However, the alternative to this generalising of the property name would be to recognise a distinct 'deliveryLocation', 'licenseLocation' etc. so open to suggestions on this.

On Tue, Mar 24, 2015 at 11:04 AM, Myroslav Opyr notifications@github.com wrote:

It would be great to have some examples of gazetteer and activityLocation (specifically something like point, line (road), circle, polygon) property values.

The question about activityLocation vs deliveryLocation. Can "delivery" be treated as place for service delivery? This way the same property can be used for tangible and intangible procurement items.

— Reply to this email directly or view it on GitHub https://github.com/open-contracting/standard/issues/26#issuecomment-85452013 .

+44 (0)7834 856 303 @timdavies http://www.timdavies.org.uk

— Reply to this email directly or view it on GitHub.

timgdavies commented 9 years ago

Below is a quick worked example of combining a point location in Cumbria, with a set of region descriptions from the NUTs classifications. In practice, most use-cases would choose between point location and gazetteer, but we make it at least theoretically possible to mix them. 


"activityLocation": {
     "description":"Scotland, North West England",
     "geometry": {
          "type":"point",
          "coordinates":[54.5, -3.25]
      },
      "gazetteer": {
          "scheme":"NUTS",
          "identifiers":["UKA","UKD"]
      },
     "uri":"http://nuts.psi.enakting.org/id/UKD/"
}
myroslav commented 9 years ago

FYI, the primary idea for deliveryLocation was the places that do not have postal address yet. The other possible use case is exact delivery place in cases where postal address is too general to be informative (i.e. the exact hangar in huge industrial complex). And yet another case is some road works, but geometry would probably help in that case more.

timgdavies commented 9 years ago

Ok - so it's sounding to me like having deliveryLocation rather than activityLocation is important for the procurement context, and can capture both tangible and intangible examples.

If later modifications to incorporate concessions need it, then they could add activityLocation separately (using same model as deliveryLocation). Does that sound reasonable?

timgdavies commented 9 years ago

This is now summarised in issue #250, which can be used for further discussion.