Docs say &layers= but actually &placetype=

[azaroth42]

Describe the bug

The documentation says to use the layers parameter to filter by the type of Feature. This does not make any difference to the results.

Instead it should be placetype (thanks to #55 for the hint on this)

[missinglink]

Hi @azaroth42, thanks for reaching out, pelias/placeholder (this repo) and pelias/api have different APIs.
You're absolutely right in noticing that the two repos have differing variables names for similar concepts.

The pelias/api parameter is named layers, this is a more generic term which allows us to include things which aren't only a 'placetype'.

The pelias/placeholder parameter is named placetype, this terminology is inherited from the whosonfirst project and only refers to administrative areas (locality, state, country, etc) but not things like street,address which are valid 'layers' in the pelias/api vernacular.

I think the confusion lies in pelias/placeholder being a 'mircoservice' for pelias/api which I guess you could call the 'macroservice' here, it's the 'external API' of Pelias, whereas Placeholder is usually not exposed to the internet.

The pelias/documentation refers to the external API only and doesn't include any references to, or documentation for, internal services, for that it's best to refer to the readme for this repo.

[missinglink]

The easiest way of differentiating between the two is to check the URL path.

The pelias/api endpoints all start with /v1 such as /v1/search?text=YMCA&layers=venue,address (in the docs)

IIRC all the pelias/placeholder endpoints all begin with /parser/ such as /parser/search

They also run on different HTTP ports.

[azaroth42]

Should there be the link to documentation in the header of the readme then? That was where my confusion stemmed from -- now I do see the difference in the readme for placetype, thanks!
Or at least a warning to this effect?

[missinglink]

Agh yes, I see, that's a standard header we use on all the repos, I can see how that's confusing 🙇