Bugs in Add new place flow

[holgerd]

There are some issues when creating a new node using https://wheelmap.org/en/nodes/new/name_category

This Issue is for me to collect the issues and clarify them.

Issue 1: geocoder finds wrong housenumber

• I add a place Final Escape Berlin, Prenzlauer Allee 23, 10405 Berlin and fill in the form in the flow
• I expect the geocoder to find "Prenzlauer Allee 23" or notify me when this was not successful
• Instead, the location is set to "Prenzlauer Allee 230" (on the opposite side of the street). This is the changeset: http://www.openstreetmap.org/changeset/44080470 . I now manually moved the node to the correct building (this is the changeset correcting the location with iD editor: http://www.openstreetmap.org/changeset/44080675 ).

[schultyy]

I did some debugging on this issue. What I found out so far:

• The case described above is specific to some places. E.g. when I search for Suarezstr. 1 14057 Berlin, it appears on the correct side of the street
• I searched for Prenzlauer Allee 23, 10405 Berlin on https://photon.komoot.de/ and there it renders the place on both sides of the street

[schultyy]

Interestingly when I check what the Photon request the browser makes returns, we only get back Prenzlauer Allee 230:

$ curl -XGET "https://photon.komoot.de/api?limit=1&q=Prenzlauer%20Allee%2023%2C%2010405%20Berlin" | underscore pretty
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   354  100   354    0     0   1144      0 --:--:-- --:--:-- --:--:--  1145
{
  features: [
    {
      geometry: { coordinates: [13.419891, 52.5325281], type: "Point" },
      type: "Feature",
      properties: {
        osm_id: 4236203789,
        osm_type: "N",
        country: "Germany",
        osm_key: "shop",
        housenumber: "230",
        city: "Berlin",
        street: "Prenzlauer Allee",
        osm_value: "bicycle",
        postcode: "10405",
        name: "Kiezradler",
        state: "Berlin"
      }
    }
  ],
  type: "FeatureCollection"
}

[schultyy]

Doing the same with limit=2 returns first Prenzlauer Allee 230 as before but then also Prenzlauer Allee 23:

$ curl -XGET "https://photon.komoot.de/api?limit=2&q=Prenzlauer%20Allee%2023%2C%2010405%20Berlin" | underscore pretty
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   646  100   646    0     0   1844      0 --:--:-- --:--:-- --:--:--  1845
{
  features: [
    {
      geometry: { coordinates: [13.419891, 52.5325281], type: "Point" },
      type: "Feature",
      properties: {
        osm_id: 4236203789,
        osm_type: "N",
        country: "Germany",
        osm_key: "shop",
        housenumber: "230",
        city: "Berlin",
        street: "Prenzlauer Allee",
        osm_value: "bicycle",
        postcode: "10405",
        name: "Kiezradler",
        state: "Berlin"
      }
    },
    {
      geometry: { coordinates: [13.4204389, 52.5320266], type: "Point" },
      type: "Feature",
      properties: {
        osm_id: 2139376669,
        osm_type: "N",
        country: "Germany",
        osm_key: "place",
        housenumber: "23",
        city: "Berlin",
        street: "Prenzlauer Allee",
        osm_value: "house",
        postcode: "10405",
        state: "Berlin"
      }
    }
  ],
  type: "FeatureCollection"
}

[schultyy]

The reason for the strange behavior that the address sometimes is a bit off is that we get back multiple results from Photon. My first attempt to solve this was to be a bit intelligent on which result to take by matching the street name and the house number with the address the user entered. But turns out it's rather difficult for a couple of reasons:

• I search for Ohlauer Str. The result's street name is Ohlauer Straße. I could match "Ohlauer Straße" with a substring match.
• I search for Ohlauer Str.. The result's street name is Ohlauer Straße. Checking for equality and for substring wouldn't deliver any results because of the dot in my search string.

I'm not sure if it is worth the effort to normalize user input accordingly so that it's possible to match it against the Photon search results. Also the result set does not contain any scoring which would make it easier to pick the correct address.

To solve this, we could do the following: If we get back more than one result from Photon the user needs to pick the correct one from a list populated with everything we got back from Photon. It's a bit more effort for the user but we avoid that places have the wrong coordinates afterwards.

Does that sound feasible from a product perspective?

[holgerd]

As discussed on slack

1. check back with photon developers if the might have a "best match" or other solution to this behavior. If not, then 2.If we get back more than one result from Photon the user needs to pick the correct one from a list populated with everything we got back from Photon. This is IMHO a good solution because it provides context to the user and also a feeling of progress. My hunch is that this won't affect the user experience in a bad way.

[holgerd]

@schultyy what is the status of this?

[schultyy]

@holgerd I started implementing this before the Christmas holiday. This is work in progress.

[holgerd]

We discussed today that we put this on hold for now.