SeeClickFix uses ESRI for map and our town has wrong name because of it

1085
8
11-21-2019 11:49 AM
Status: Open
Labels (1)
SaraBrumm
New Contributor II

I work for the Town of Carolina Shores in North Carolina.  We are a new town (21 years) that is a split off from another town, and we have the same zip code (USPS will not give our town a different zip code).  We started using SeeClickFix a little over a year ago, and their map had our town name listed correctly.  Several months ago we noticed that our map now had our town name as the other town.  After multiple attempts to get them to correct it, they said that the change happened when they switched to using ESRI.  We need our service requests for our town to have the correct town name on it.  We will provide whatever we need to to show that we are our own town with a different name that what is listed because of the zip code.

8 Comments
KoryKramer

Hi Sara Brumm‌ Please go to http://www.arcgis.com/home/item.html?id=2f943ed1c05141a2a0f1351a215266b4 and provide the feedback through that channel.  

Thank you!

SaraBrumm

I did that when we first noticed the issue and have never gotten a response and nothing has changed.

Sara W. Brumm

Office Assistant

Town of Carolina Shores

200 Persimmon Road

Carolina Shores, NC 28467

(910) 575-4877

(910) 575-4812 (fax)

<mailto:sbrumm@atmc.net> sbrumm@atmc.net

KoryKramer

Hi Sara,

In the description you said you work for the Town of Carolina Shores, and in the email signature we see both Town of Carolina Shores as well as Carolina Shores, NC 28467.

When you say that the town is incorrect, or listed incorrectly, can you provide screenshots and some more details about what that means?

I see Carolina Shores on the basemap.  Is this supposed to say Town of Carolina Shores?  Or is Carolina Shores correct?  And is it in the correct location?

When I search in Google Maps for zip code 28467 this is what I see:

and searching in arcgis.com for zip code 28467 I see this:

When I visualize Populated Places from the Geographic Names Information System (Geographic Names Information System (GNIS) - USGS National Map Downloadable Data Collection - Data.g... ) it looks like the basemap is correct.

Based on the above, I'm assuming the issue you're reporting is specific to the zip code search?  

USPS provides the following

I went over to SeeClickFix and if I'm on a submit screen and need to search for a different area, this is the experience I see when searching solely by zip code:

Is that what you're referring to?  The suggestion for 28467 that includes only Calabash and not Carolina Shores?  Assuming that, I went to the geocoding feedback basemap, and found the following:

The description of the error says "Area shows as Calabash in SeeClickFix instead of Carolina Shores".  It would be helpful to get screenshots from SeeClickFix, along with the corresponding URLs that provide more details about what and where the issue is in SeeClickFix, so that our teams can understand if this is something that can be corrected in our databases.

Sorry for the long-winded response, but it took me a while to get to this point, and I may still be making assumptions about the problem you're trying to convey.  Thank you in advance for taking the time to provide further details to help us understand the issue. 

SaraBrumm

When I say I work for the Town of Carolina Shores, I literally work for the town government for Carolina Shores. Our town name is Carolina Shores. We share a zip code with Calabash. In SeeClickFix we enter service requests from residents. The map says Carolina Shores but all of our requests are fixed with a Calabash address (see attached). I never got any reply from arcgis stating they needed more information from us about the problem I submitted to them, and I don’t know what else they need from us.

Sara W. Brumm

Office Assistant

Town of Carolina Shores

200 Persimmon Road

Carolina Shores, NC 28467

(910) 575-4877

(910) 575-4812 (fax)

<mailto:sbrumm@atmc.net> sbrumm@atmc.net

KoryKramer

I don't see an attachment

SaraBrumm

I apologize, I was using my email to reply.  Here is what I attached.  

ThomasColson

This is a perennial problem for many jurisdictions. We went through the process of providing our data to the ESRI basemaps team, and they were spectacular in terms of support, feel like I had a dedicated consultant working with us, but then we found out that they do a cyclic update using (HERE! Teledata? ??) commercial services, and replaced our authoritative and accurate data with unvetted and very inaccurate data, which actually leads to some pretty significant public safety issues (e.g a 911 caller looking at some app on their phone saying they're at Sasquatch Overlook, we can't get a ping off their phone, and it turns out they're really at Bigfoot Overpass).  The solution was (is) for us to have to continually keep updating the basemap program, which is not sustainable, and led to us developing our own tile basemap service. 

But not to uniquely throw ESRI under the bus, we have the same problem with all of the location based service providers, and provide very detailed messaging to the public about why those maps should not be relied upon in our jurisdiction, and additional very detailed steps on how to access authoritative and accurate location-based products. 

As a fine-tune to the idea, the idea should be:

When a jurisdiction provides authoritative data to the ESRI basemap program, that data should not then be overwritten by data from a non-authoritative, un-verified source. 

I had some email exchanges with the BM team regarding re-correcting our data in the BM, but again, my workload is such that I just can't keep up with having to re-vet our already submitted data once or twice a year. This thread may be the motivation I need to follow up on that, but I'd need confidence that ESRI is not going to continue to overwrite our data and expose users of their map products to hazards or destruction of our property and resources by overwriting our data with inaccurate and misleading data. 

Perhaps an additional idea would be modifying the basemap partner dashboard to alert jurisdictions that data is about to change, or provide a click-once-per-year checkbox or something....

The problem with the feedback link provided is "...we'll forward the feedback to our data provider to be addressed in an update." we have spoken directly with many of the data providers (I think there's 2 or 3), and they have told us directly that they do not consider our data sources, and refused to provide details on how they're mapping, for example, a non-existent road going straight up a mountain. 

Another problem, and I'm fuzzy on the reason for this, but I vaguely remember the BM team telling me because of licensing, they could only show our data at certain zoom levels (e.g if I'm at zoom level X, the non-existent road will be shown), AND, our authoritative data would only be included in the tiled base maps, we have no input into the streets product.

Looking at the examples below, I have to wonder what QA process allowed this?

BradNiemand

By default the World Geocoding Service returns the Postal City name for addresses in the USA.  There is a way to change this by configuring a locator (view) on top of the World Geocoding Service and specifying that the preferred city should be the "Local City" or the "Matched City" and any results returned for that city will use one of those options instead of the "Postal City" where the data is available.

More information about Locator (views) can be found here:

https://doc.arcgis.com/en/arcgis-online/reference/geocode.htm#ESRI_SECTION1_BC67C473527D4AD4A51F24B5...

Brad