Closed dalekunce closed 8 years ago
Wouldn't this require us to assume that there are correct street names already in the OSM file? What if we want something different than what is in the OSM file?
It does assume the roads are correct. So we would need to have an "other" option that allows a free text field.
I'm thinking we should have a "Constraint Sprint" that focuses on adding constraint functionality like #40 #21 #20 #17
In fact, could you add an issue tag for constraints so we can isolate these issues for a specific sprint / feature branch?
What if we had a constraint where we read and index values of a tag from the main source OSM file?
Rather than have multiple choice UI, we could have a typeahead. For this use case, we could index key name
on all of the ways with the tag of highway
.
Typeahead might make a bit more sense, because we might have quite a few tags we want to have indexed.
Should we rename this Typeahead Based off of Tag Index?
AutoCompleteTextView looks perfect for our needs. You just feed it with an array of strings for autocomplete.
An option that might be simpler than specifying which tags to index for autocomplete is to just do this automatically for everything parsed with the same tag key.
For example, I think the current StringTagValue widget should do this. If it is for a tag of the key name
, we should look at everything parsed from source OSM as well as previous responses with the tag key of name
. Provide autocomplete suggestions based off of that.
Yes, we want to seed the autocomplete array with everything parsed for the same tag key, but we also want to be able to correlate one key to the value of another element with a certain key.
For example:
When tagging a building, we want a typeahead for addr:street
to refer to the name
of all of the highway
s parsed.
This one will be a huge time saver.
iD already does this and its awesome.
Looking at this feature and the limited time I have to sprint on constraints, I'm going to go with the JOSM approach of having a simple typeahead that autocompletes all tag values parsed. I'm going to put the most recently used values at the front of the array so that if you are, for example, putting in an addr:street
over and over again, the latest chosen autocomplete will show up first.
This approach is more generic and will satisfy the use of any text input. Going that extra mile by sorting by spatial operations should be done in a future sprint once this basic functionality is implemented.
Whoo!!!
Implemented typeahead auto complete in the custom select one / select multiple inputs as well.
This is fantastic.
There's some bug preventing the typeahead from always working. Investigating...
APK was in inconsistent state, should be fine.
Survey grid Street Names
looking at the data we gathered from Zimbabwe I think we should we look into populating some select_one fields with data from the osm file. For instance volunteers were really good about adding street names to building address but often have spelling and/or capitalization errors. Populating the street name field with only those features within a bounding box would help eliminate this problem.