Cartodb: Georeference by street address is lacking custom fields addition
Context
Previously, users could add extra custom fields for specifying the rules of georeferencation by street address. It's not longer there!
Steps to Reproduce
- Create a layer with this file Relacion Camaras.csv.zip
- Georeference by street address.
Current Result
It's impossible since number and street are in different fields.
Expected result
As in editor, you should be able to add fields to the form right after street one
saleiva
All 33 comments
Please, add design link when it is ready 💋 .
xavijam
on 28 Feb 2017
These are the visuals when the option "Street Addresses" is selected
urbanphes
on 28 Feb 2017
Is this supported / implemented in Camshaft?
According to the last camshaft reference there are no additional columns available for this analysis. They are the same as shown in the UI.
I don't know if we can send additional info to street_address_column encoded somehow in the string or not.
Summoning @rochoa to answer this.
ivanmalagon
on 2 Mar 2017
As @ivanmalagon is pointing, georeference-street-address does not support custom fields for the street_address_column param. Do you know how was that working before? Were we manipulating the query to _concat_ the different columns?
rochoa
on 2 Mar 2017
In editor we were doing this by calling to geocodings API filling formatter field with comma-separated values.
endpoint: POST /api/v1/geocodings/
payload:
{
"kind":"high-resolution",
"formatter":"{calle}, {numero_de_finca}",
"table_name":"relacion_camaras",
"state":""
}
Hey designers, one question. The typical usage for this is "{street_adress_column}, 28010 (Madrid)" rather than a column concatenation.
Don't you think we should have a more open way to do it using templates? cc @noguerol
javisantana
on 6 Mar 2017
Although I love the idea (and I'm tempted to add it anyway) I think is risky because:
- The query structure makes some providers to work better under some circumstances, so this would let users to remove commas for example when using mapzen, which is not ideal.
- This adds a bit of functionality such as the validation.
Anyway, I do think this is something we would like to add to the product anyway, so if you guys don't see these hazards, I'd be down to it.
saleiva
on 6 Mar 2017
The query structure makes some providers to work better under some circumstances, so this would let users to remove commas for example when using mapzen, which is not ideal.
I thought that was the proposal: provide more flexibility to allow fine tuning of the string. Do you think that might introduce problems when we switch providers? If so, how often do you think we are gonna be switching providers?
This adds a bit of functionality such as the validation.
I guess you are talking about Builder validation, but what about the expected error message from the backend? Do you expect it to be as explicit as possible? Something in the line Missing column `address_number` for your template '{address_name}, {address_number}. 28004 Spain'?
rochoa
on 7 Mar 2017
1) We have already identified some patterns that work pretty bad with Mapzen but at the same time works pretty well with gmaps.
2) That could be a solution yeah, not the best UX, but I understand the reasons.
saleiva
on 7 Mar 2017
So what's the decision guys - 1) templates or 2) fields?
If 1), we need new UI mockups
jorgesancha
on 7 Mar 2017
2) has to be there, I don't think we can afford to remove that UI right
now. about 1) I'm happy to add if you think we can afford it
El mar., 7 mar. 2017 a las 15:03, Jorge Gomez Sancha (<
[email protected]>) escribió:
So what's the decision guys - 1) templates or 2) fields?
If 1), we need new UI mockups
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/11662#issuecomment-284729360,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIENRLqp37EcbPNwfIFA3MidAF4yBQQks5rjWOWgaJpZM4MOSUX
.
saleiva
on 7 Mar 2017
My point with this is: the template thing is what our client was using so don't know if that would work for them.
In the other hand it's clear each geocoder provider should have it's own UI since the way the work best depend a lot on how we provide inputs.
javisantana
on 7 Mar 2017
I agree with Santana. In any case, it is your decision, product guys. It is the right time now to decide.
From my point of view, doing the columns (or just the columns) seems like a missed opportunity to implement something that can be adapted to fit any provider and use case.
Please tell us:
- If we use columns as in the UI, what should we send to the Geocoder (separated by commas, spaces, etc.)
- If we add the template, how the UI would look.
jorgesancha
on 7 Mar 2017
ok, so following the conversation with @saleiva and after hearing your comments we are deciding to go with the UI. It is possible currently to enter fixed values and/or columns for each of the different fields. So finishing CartoDB/camshaft/issues/267 should enable this.
Ideally, we would concatenate the columns in the ideal way for each provider (this is for Engine to decide), but maybe we can prioritize separately
jorgesancha
on 7 Mar 2017
ok, so following the conversation with @saleiva and after hearing your comments we are deciding to go with the UI. It is possible currently to enter fixed values and/or columns for each of the different fields.
Not, it's not possible at backend level. The backend will receive strings, making impossible to determine if what the user wants is a column or a fixed string. So if we want to support a mix of columns and fixed strings we cannot use this approach and we need to use the template approach.
Ideally, we would concatenate the columns in the ideal way for each provider (this is for Engine to decide), but maybe we can prioritize separately
It's not only about the provider, it's also about the context: for instance, the street number in some countries should be prepended and for other, it should be appended. So I would say that's something we should make the user responsible for, that's why the UI uses a list (or it should use a template).
rochoa
on 8 Mar 2017
what? sorry I don't get it. Let's discuss tomorrow in person
saleiva
on 8 Mar 2017
We need to change the approach here @CartoDB/design
saleiva
on 9 Mar 2017
Hey, you can see how we solve this.
The idea is to have the option to put code instead of select only a column. For that, there is an action to change the input to code mode. We should review the copys.
Here's the InVision project
https://invis.io/9GASYTMND
cc/ @CartoDB/design
urbanphes
on 13 Mar 2017
The template should only have effect in the "street address" param, we want to keep city, state, and country parameters still available.
rochoa
on 13 Mar 2017
no no no, that's impossible to handle from the UI perspective... I'd make one or the other one. Anyway, let me give some feedback to that design
saleiva
on 13 Mar 2017
Why is it impossible? We want to change the "street address" param, not the rest.
rochoa
on 13 Mar 2017
@urbanphes, Some feedback about the designs:
- I do think we should show autocomplete whenever the user starts with {{ or whenever we detect the 3 first chars of a column name. When clicking on a column name on the autocomplete, we should make sure that we enclose the column name between {{ }}
- Colors should help for differentiating strings and columns.
@rochoa about your comment, If you leave the country to be defined like that we would be in the same situation where we cannot choose the separator we want for example. Also, from the usability perspective is going to be very challenging to make people understand that country and so on is after whatever they write. I think very often they will tend to attach the country name to the "template".
saleiva
on 13 Mar 2017
@rochoa about your comment, If you leave the country to be defined like that we would be in the same situation where we cannot choose the separator we want for example. Also, from the usability perspective is going to be very challenging to make people understand that country and so on is after whatever they write. I think very often they will tend to attach the country name to the "template".
Fair enough. I was thinking more in the future, where we could have structured geocoders. But we can re-evaluate the proposed solution when that moment arrives. 👌 .
rochoa
on 14 Mar 2017
Hey guys, let us "add" block label until the functionality is available in engine (I guess there is another ticket there). 💋
xavijam
on 15 Mar 2017
I updated the mockups with:
- Autocomplete.
- Color for differentiating strings and columns.
Here's the InVision project:
https://invis.io/9GASYTMND
urbanphes
on 16 Mar 2017
I updated the mockups with:
- Advanced Mode only applies to Street Address input.
- Info help and link to more info.
Here's the InVision project:
https://invis.io/9GASYTMND
cc/ @saleiva @rochoa
urbanphes
on 17 Mar 2017
Close and promote @urbanphes !
saleiva
on 17 Mar 2017
whoever takes this, can you guys make sure we have a quick meeting between you, @urbanphes and me?
saleiva
on 24 Mar 2017
@saleiva this ticket is on CartoDB repo, I can't close it.
The meeting when you want. Tell me.
urbanphes
on 29 Mar 2017
found some issues already reported in the PR.
saleiva
on 18 Apr 2017
Blocked until tracking UI classes are added.
xavijam
on 24 Apr 2017
Deployed!
xavijam
on 25 Apr 2017
BOOM
On Apr 25, 2017 1:47 PM, "Javier Álvarez Medina" notifications@github.com
wrote:
Closed #11662 https://github.com/CartoDB/cartodb/issues/11662.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/11662#event-1056489144, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACPRCcSLnyo-TiUMg_st-DvdTIn7WTcks5rzd1dgaJpZM4MOSUX
.
matallo
on 25 Apr 2017
Related issues
arianaescobar
·
5Comments
noguerol
·
5Comments
jesusbotella
·
4Comments
javitonino
·
5Comments
nygeog
·
5Comments
Most helpful comment
Close and promote @urbanphes !