agrc / api.mapserv.utah.gov Goto Github PK

dev keys are open to any use from anywhere. need to limit the usage of these so they don't sneak into production. Cap uses per day? Have them expire?

This would make me :).

When running /geocode low quality addresses will return multiple matches with similar scores. However, when running with /geocode/multiple it becomes impossible to tell that an address is low quality. If we had some way to know that there were multiple 'good' matches, we could then flag those for later processing using the non-batched /geocode.
For example: 201 main street and SLC (with acceptScore = 90) in the Single Geocode returns:

{
 "result": {
  "location": {
   "x": 424785.93550203653,
   "y": 4514020.436742754
  },
  "score": 90.97,
  "locator": "Centerlines.StatewideRoads",
  "matchAddress": "201 N MAIN ST, SALT LAKE CITY",
  "inputAddress": "201 main street, slc",
  "addressGrid": "SALT LAKE CITY",
  "candidates": [
   {
    "address": "201 S MAIN ST, SALT LAKE CITY",
    "location": {
     "x": 424827.46269343514,
     "y": 4512996.445548089
    },
    "score": 90.87,
    "locator": "AddressPoints.AddressGrid",
    "addressGrid": "SALT LAKE CITY"
   }
  ]
 },
 "status": 200
}

The multi geocode returns:

{
 "result": {
  "addresses": [
   {
    "id": 1,
    "location": {
     "x": 424785.93550203653,
     "y": 4514020.436742754
    },
    "score": 90.97,
    "locator": "Centerlines.StatewideRoads",
    "matchAddress": "201 N MAIN ST, SALT LAKE CITY",
    "inputAddress": "201 main street, slc",
    "addressGrid": "SALT LAKE CITY"
   }
  ]
 },
 "status": 200
}

The suggestion is to add some sort of indicator that multiple matches were found.

{
 "result": {
  "addresses": [
   {
    "id": 1,
    "location": {
     "x": 424785.93550203653,
     "y": 4514020.436742754
    },
    "score": 90.97,
    "locator": "Centerlines.StatewideRoads",
    "matchAddress": "201 N MAIN ST, SALT LAKE CITY",
    "inputAddress": "201 main street, slc",
    "addressGrid": "SALT LAKE CITY",
    "multipleDetected": true
   }
  ]
 },
 "status": 200
}

For example:
https://api.mapserv.utah.gov/api/v1/search/SGID10.BOUNDARIES.Counties/NAME?predicate=salt&apiKey=AGRC-Explorer

Returns:

{
 "status": 400,
 "message": "SGID10.BOUNDARIES.COUNTIES probably does not exist. Check your spelling."
}

whereas:
https://api.mapserv.utah.gov/api/v1/search/SGID10.BOUNDARIES.Counties/NAME?predicate=NAME+LIKE+'salt%25'&apiKey=AGRC-Explorer

returns the expected feature

{
 "result": [
  {
   "attributes": {
    "name": "SALT LAKE"
   }
  }
 ],
 "status": 200
}

The docs

Search criteria for finding specific features in featureClass. Any valid ArcObjects where clause will work. If omitted, a TSQL * will be used instead. eg: NAME LIKE 'K%'

read to me as if these two requests should return the same results.

Add

• slc and midvale avenue address
• #45

@MichaelAGRC just told me that the server that this project is on is trying to hit SGID93 on 112. I assume that this project is the one doing that but not positive.

{
 "result": {
  "inputAddress": "5292 w brush creek bay, 84120",
  "scoreDifference": 0
 },
 "status": 404,
 "message": "No address candidates found with a score of 70 or better."
}

vs

{
 "status": 404,
 "message": "No address candidates found with a score of 70 or better."
}

The latter is the right response. This is probably related to #47

the ^1.x version only has po box locations from Neil Hood's group. We need someone to take the po box numbers and tie them to a location.

@BGranberg we spoke about this once in depth, do you remember how the data needed to be organized?

google allows you to do 1.2.4.0/25 to imply that the subnet range will be 0 through 25. Consider this for the web api.

"Wing Pointe" Dr will not geocode in the api geocoders as "Wing Point" Dr
sample (real world) address that codes: 3501 S Wing Pointe Dr Salt Lake City
sample (not real world) address that does not code: 3501 S Wing Point Dr Salt Lake City

When I submit a point in web mercator to the reverse geocode service I get no results.

For example:
x: -12449589.63970003
y: 4965953.392828723
distance=50
spatialReference=3857

yields

{"result":{},"status":200}

whereas the same point in utm works:

x: 429309
y: 4504098
distance: 50
spatialReference: 26912

{"result":{"inputLocation":{"x":429309.47224767046,"y":4504099.0752038416},"address":{"street":"4002 S 1925 E"}},"status":200}

If the address looks like midvale (zip or city) add a W if there's no prefix dir

If the address looks like Salt lake City (zip or city) add a E if there's no prefix dir (OR this could just be the default)

think about geocoding the address returned by the reverse geocode to then get distance and angle of the line created by them. return those values.

allow for esri json to be used instead of point:[x,y] syntax.
allow non 26912 geometries to be used.

Conversion.ToGeometry(); // makes it simple to make an IGeomery from the json

This happy paths esri devs but what do we do about folks who have an x,y field in a database?

I'm not sure that this is an across-the-board issue but for the below-stated addresses, they will not code when supplying the street type. If you remove the street type they code, but when you look at the segment/point they matched on that segment/point contains the street type.

• 9211 N Pebble Creek Loop, Eagle Mountain 84005
• 5811 W Park West Rd, Provo 84003

When searching on a vanilla table with a spatial query we puke an ugly error.

http://api.mapserv.utah.gov/api/v1/search/SGID10.BOUNDARIES.UTAHLAWENFORCEMENTAGENCIES/County?geometry=point%3A+%5B443072%2C4460865%5D&apiKey=AGRC-ApiExplorer

{
status: 400,
message: "ERROR HRESULT E_FAIL HAS BEEN RETURNED FROM A CALL TO A COM COMPONENT." 
}

Return a better error message.

When someone geocodes with difference on and suggest off, request one candidate. Calculate the difference between scores of the top two results and tack it on to the geocode response.

1. Add boolean property to single/multiple geocodes to include difference. Defaults to false
2. Update api testing docs to include difference with a description.
3. Provide the difference property on single and multiple geocodes.

refs #32

This would allow us to use the geocoding web api from arcgis online.

http://mapserv.utah.gov/arcgis/sdk/rest/index.html#/Geocode_Service/02ss0000003n000000/
http://mapserv.utah.gov/arcgis/sdk/rest/index.html#/Find_Address_Candidates/02ss00000015000000/

Find_Address_Candidates has a lot of parameters that we may not need. Maybe Michael can forward a link to an AGOL map that uses an address locator so that I can check out what parameters it uses?

[email protected]

I've run across something that might be a small bug in the geocoding API. I didn't do thorough testing, but it appears that if a suite number on an address contains an alpha character, the geocoding fails:

http://api.mapserv.utah.gov/api/v1/geocode/1151 E 3900 S Ste B150/84107?spatialReference=4326&pobox=true&apiKey=AGRC-ApiExplorer

vs.

http://api.mapserv.utah.gov/api/v1/geocode/1151 E 3900 S Ste 150/84107?spatialReference=4326&pobox=true&apiKey=AGRC-ApiExplorer

I would expect this request to return a "Name" field: http://api.mapserv.utah.gov/api/v1/search/SGID10.LOCATION.ZoomLocations/Name?predicate=UPPER(Name)%20LIKE%20UPPER(%27utah%25%27)&apiKey=AGRC-ApiExplorer&attributeStyle=identical

But it returns "NAME".

if input address is based a numeric streetname formatted address do not return a match where the found address has a different prefix direction or suffix direction (even from acs alises)

example:

677 E 1600 N Centerville should not return a match but currently returns: 677 W 1600 N, 84014 (input and result prefixes do not agree)

BUT allow for reversals

It supports jsonp but doesn't have the doc property.

@rkelson struggles to geocode these types of addresses. The current web api probably barfs on them as well. We should figure out how we want to try to match these if at all.

spatialReference is implemented.
spatialReference is a number

add 3857 Web Mercator to Popular WKID's

make this a first class citizen

Missing 33 S Haulage in Eureka in the address points

Address range on 6639 W 3000 S, Roosevelt has some funky ranges.

Geocoding on that address with the ACSALIAS gives 3 100% matches. The correct range is on the yellow dot on the right.

create a page where an admin can generate exemptible keys for applications so they aren't tied to a specific user.

I had someone ask me this question and I didn't find it right away in the code. We should probably add it to the docs as well.

There has been a few occurances where the city/zone values contain city of or town of.

Strip those two strings out of zones if they are not zip codes.

Improve admin analytics

• endpoint request counts
• endpoint request counts by user
• sgid layers searched
• requests per month
• requests per day
  • client.set(key, value, 'EX', 60 * 60 * 24); expire requests monthly
• total requests per user

http://byterot.blogspot.co.uk/2014/11/health-endpoint-in-api-design-slippery-rest-api-design-canary-endpoint-hysterix-asp-net-web-api.html

Add this privacy policy

Input parameter values submitted in requests to the web API may be temporarily retained by AGRC exclusively for the purpose of overall quality control and performance tuning of the web API conducted by AGRC employees. No other access to or use of input parameter values will be permitted without prior written approval of the State's Chief Information Officer and the executive officer of the agency submitting requests to the web API.

THE POINT USED TO DO THE QUERY IS FOULED UP. CHECK THE SYNTAX POINT:[X,Y]"

• Also double check that the predicate is applied.

I had 4,000 cases of S Salt Lake being used instead of South Salt Lake and it prevented matching. Should we have and alias for S Salt Lake?

in version ^1.x we introduced a hidden flag to keep attributes cased the same way they are in the data. The camelCase code we use munged data.

I propose we remove the camel case option and introduce

• upper
• lower
• data (make default)

collapse navigation when viewed on small viewport ie mobile.

remove beta flag.

The ^1.x version returns a polygon when requesting the shape@envelope token.

Look into returning an extent geometry for at least the esrijs response format.

Would it be possible to create a docker container for this project? I'd like to get my hands dirty and give #30 a try. Wondering if it's worth trying to set up this on my VM or if docker would be feasible.

I get

{
Message: "An error has occurred."
}

returned from this request: http://api.mapserv.utah.gov/api/v1/geocode/milepost/15/5?spatialReference=3857&apiKey=AGRC-ApiExplorer

It returns successfully when I remove the spatialReference parameter.

http://api.mapserv.utah.gov/#search

Here's what I have in the WebAPI.js docs:

// options.attributeStyle: String (defaults to 'identical')
            //      Controls the casing of the attributes that are returned.
            //      Options:
            //
            //      'identical': as is in data.
            //      'upper': upper cases all attribute names.
            //      'lower': lowercases all attribute names.
            //      'camel': camel cases all attribute names 

when someone puts in an ip starting with 192 or 127 or 0, alert them that it won't work.

add a boolean flag to replace search result attributes with their alias values.

Some address points seem to carry the unit #. The api strips it. We might get more accurate matches on unit numbers if we either don't strip them or geocode them with and without for address points only.

these are all 777 s 400 e in STG

This address does not reproject to 4326.

{
    result: {
        location: {
            x: 423479.84389717487,
            y: 4501799.815681645
        },
        score: 89.04,
        locator: "AddressPoints.AddressGrid",
        matchAddress: "4973 S MURRAY BLVD, SALT LAKE CITY",
        inputAddress: "4973 SO MURRAY BLVD #N24, 84123",
        standardizedAddress: "4973 south murray #n24 boulevard",
        addressGrid: "SALT LAKE CITY"
    },
    status: 200
}

This address fails to geocode, because the street name lacks the 'e' at the end: point vs. pointe.

Fails:
http://api.mapserv.utah.gov/api/v1/geocode/5974%20FASHION%20POINT%20DR/84403?apiKey=

Works:
http://api.mapserv.utah.gov/api/v1/geocode/5974%20FASHION%20POINTE%20DR/84403?apiKey=

This issue pops up about 30 times in Utah NPPES addresses, but as far as I can see, only for this particular street. Most addresses in NPPES seem to use 'point' without an 'e'.

Not sure if this is something that should be solved server-side, client-side, or in the underlying data. Google seems to have the street name listed as 'point', by the way.

Currently the geometry parameter supports only points. Expand this to support bounding boxes and possibly polygons.

There should be some way to prevent users from making requests that would overwhelm the server. I would suggest a feature limit (with some sort of warning in the returned data) rather than a limit on area (which is dependent upon the distribution of the data being queried).

We created 5 locators with a 5 meter offset.

they are named "Roads_AddressSystem_" + STREETNAME_5M, ALIAS1_5M, ALIAS2_5M, AND NoPrefix_5M

Add an option to the locators dropdown to use these locators.

We did this 3 years ago and have not used them. Do we still have a need for these?

need to work out the web config/secrets etc before publishing to github

It appears to be what people expect.

refs #32

Streets that don't have both an east and west (or a north and a south?) For the east and west, we want to end up with the shortest list........whether that be exceptions or the rule.

the unnecessary prefix (n, s, e, w) directions in utrans roads have been removed. We need to add prefix directions to the roads in utrans where needed. We will then create a google doc of the roads that need prefix directions (or not)...whatever is smaller.

I think we were supposed to implement something where an address that doesnt cross main street or need a prefix direction gets sent at a different locator. Kelly has built the locators but not the list of addresses to determine when to add this rule.

Is this still something we want to implement?