Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add categories for streets (address and address:street) #241

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Joxit
Copy link
Member

@Joxit Joxit commented Jan 22, 2020

Backround

from pelias/api#1405 (comment)

I found something else, there are no categories for addresses (from OSM and OA) and streets. It might be interesting to have a category for queries like categories=admin,streets,transports (when we need cities + streets + stations).

Because of the non existence of categories for streets and addresses, we can't search both venues and addresses in one query.

What's new ?

I added categories addresses and addresses:streets. This is not yet in the taxonomy, but it can give us an idea.

I suggest for OSM and OA categories addresses and addresses:house (when addr:housenumber is present).

related pelias/api#1405

@missinglink
Copy link
Member

missinglink commented Jan 22, 2020

Heya, this is cool, thanks.

Can you please explain a little bit more about how adding categories can provide improved filtering over the existing layer field/filter which contains similar information?

"we can't search both venues and addresses in one query."

Isn't this possible already with ?layers=address,street?

@Joxit
Copy link
Member Author

Joxit commented Jan 23, 2020

The full use case is :

I'm the New York City website. I have a map with a search bar.
I want to my search to return only street, transport stations and government buildings. That means I need both layers street and venue so I can use layers=venue,street. But with this, I would still receive responses with restaurants, entertainment...
So the solution would be to have something like categories=address:street,transport,government.

If streets have no categories, they will be filtered with the categories parameter and we will get only transport and government results event if we have layers=venue,street.

@missinglink
Copy link
Member

Agh yes I understand now 😃

So.. a few thoughts:

  • doing this would potentially make the layer field obsolete?
  • the categories feature is super powerful, especially when combined with..
  • Julian's suggestions about having a negative match syntax
  • we will need to have a naming policy, eg. you called the category addresses which is plural compared to the layer name which is singular. Everyone will have their own personal preference here which we should avoid.

@missinglink
Copy link
Member

Another option would be to have a way of controlling the matching behaviour of records with zero categories.

So for instance you could ask for categories=__missing__,transport,government (for example) or by setting ?empty_categories=include/exclude

Just a thought as it would also address the specific issue, although I'm interested in the idea of having more powerful category filtering.

@Joxit
Copy link
Member Author

Joxit commented Jan 23, 2020

  • doing this would potentially make the layer field obsolete?

Hum, not really it will be still useful for admin documents and for simple use cases. IMO layer will remain an easier way to filter results but you are right layers=coarse = categories=admin.

  • the categories feature is super powerful, especially when combined with..

Yep 👍 powerful and maybe complex ?

  • Julian's suggestions about having a negative match syntax

This must be added for categories too !

I'm sorry, it's a typo, in the code it's address and address:street.

// category
doc.addCategory( 'address' );
doc.addCategory( 'address:street' );

Another option would be to have a way of controlling the matching behaviour of records with zero categories.

Yes, a feature for matching zero categories should be great. But we can't know for sure these records will be addresses or the thing we expect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants