polylines icon indicating copy to clipboard operation
polylines copied to clipboard

Add categories for streets (`address` and `address:street`)

Open Joxit opened this issue 5 years ago • 5 comments

Backround

from https://github.com/pelias/api/issues/1405#issuecomment-571228959

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

Joxit avatar Jan 22 '20 17:01 Joxit

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?

missinglink avatar Jan 22 '20 23:01 missinglink

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.

Joxit avatar Jan 23 '20 15:01 Joxit

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 avatar Jan 23 '20 18:01 missinglink

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.

missinglink avatar Jan 23 '20 18:01 missinglink

  • 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 :+1: 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. https://github.com/pelias/polylines/blob/cdceed155454e65e5f91a89eca4bde6820dc5ace/stream/document.js#L35-L37

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.

Joxit avatar Jan 23 '20 20:01 Joxit