It isn't relevant, as long as the other properties in the result match up. Leads to fragile tests.

It would be nice if we had our maps zoom according to the address type

When you click on the map marker next to the search results..

street level address should be zoomed in (zoom 14 or 15?)
neighborhood, admin level results should be at zoom 10/12?
and countries (admin0) should be at zoom 8 maybe..

Until the feedback app is redesigned, discontinue adding PRs to github with newly added tests. Continue to store the tests in mongo, make sure they are safe where they are so no data is lost. Maybe instead of PRs we just send out an email or something.

Clicking on the map marker for the first time creates a thin popup bubble. When you click on the map marker again, it resets itself to the correct width

It might make sense to always show a map with the search results instead of it being hidden and the user having to click on the map marker to see the pin on the map.

If we decide that's a good UI experience we'd like some hover functionality without it being too jarring to zoom in and out of the search result you are hovering over.

Alternatively, maybe just have colored rows with matching map markers on the map?

Lets discuss!

a daily/nightly job that

• goes through all the docs in the feedback data store (mongodb - collection:pelias)
• does some kind of sanitization/moderation (maybe?)
• commits to the acceptance-test repo (using a github bot?)
• deletes docs from data store (mongodb - collection:pelias) once the test cases are creates

• Green - if found in pelias and is the top result
• Yellow - if found in pelias but is not the top result
• Red - if not found in pelias

It might make sense for the feedback app to be private for the time being. Since the UI isn't finalized, and we don't necessarily want the general public to be entering search queries until the search quality is better, we should put it behind a password.

We just don't want it to get too much traffic yet, and this mitigates that risk.

It might be helpful to know a given user's location in conjuction with what they thought was the most appropriate result in a list of results. Sometimes this won't be useful. like when they are searching for things not near by them. But it might help you to not artificially inflate the score of a result that was only important to a specific user simply because its the best match closest to them.

techdebt

a different page "/compare" where in we can have results from two sources (pelias and nominatum for example) appear side by side and let users choose what they think is the right result.

Furthermore, we can randomize on which side pelias appears - so, we can see if people choose pelias more often or not.

Build a tool that lets the user save/discard/edit test cases populated by the feedback app. Basically, this will talk to mongodb, retrieve unmoderated documents and lets an admin edit and/or mark said document as moderated.

Maybe have a github login auth and a whitelist of users that are admins or do it at ops level - expose the link with a username/password to your admins.

Add a link to poipond.com if an address/POI doesnt exist in OSM. The tough part is to be sure it doesnt exist in OSM - just because a point doesnt show up in pelias/nominatum results doesnt necessarily mean it doesnt exist in OSM.

So, we need to be careful with the language we use. Maybe we could say "if this point doesnt exist in OSM, add it using poipond.com" ?

Sometimes pelias fetches the right location - however, the city name is incorrect

for example:
query: Giant Center, Hershey, PA
finds: Giant Center, Derry, PA
this city should be Hershey

pelias returns the following as its first result

{  
   geometry:{  
      type:"Point",
      coordinates:[  
         -76.6691266,
         40.2864639
      ]
   },
   properties:{  
      admin0:"United States",
      admin1:"Pennsylvania",
      admin1_abbr:"PA",
      admin2:"Dauphin",
      alpha3:"USA",
      id:"514080362",
      layer:"osmnode",
      local_admin:"Derry",
      locality:"Hershey",
      name:"Giant Center",
      neighborhood:"Spring Creek Manor",
      text:"Giant Center, Derry, PA",
      type:"osmnode",
      type:"Feature"
   }
}

As you can see, Hersey is locality but local_admin is set to 'Derry' and because in our outputSchema we specify the following spec, local_admin take precedence when forming the local portion of the address (properties.text)

  "USA": {
    "local": ["local_admin", "locality", "neighborhood", "admin2"],
    "regional": ["admin1_abbr", "admin1", "admin0"]
  },
  "GBR": {
    "local": ["neighborhood", "admin2", "local_admin", "locality"],
    "regional": ["admin2","admin0","admin1"]
  },
  "default": {
    "local": ["local_admin", "locality", "neighborhood", "admin2"],
    "regional": ["admin1_abbr", "admin1", "admin0"]
  }
}

It would be nice if the app UI provided a way to see all the fields that gets sent back.