Input waypoints about mapbox-cli-py

[sgillies]

Seems to me that we've got to support at least these two inputs:

• streams of coordinate pairs (either as JSON or comma-delimited pairs), the most abstract input
• geocoding output, the least abstract input

Let's put other possible inputs (GeoJSON geometries) aside for now.

To generate a list of waypoints from a list of addresses, a user needs to make multiple geocoding requests, select from multiple results for each, and probably ends up with a feature collection containing point-of-interest type features. Agree with your assessment above that this is the most common use case.

In converting those types of features to points, I think the least surprising thing to do is to compute a centroid of the feature geometry instead of exploding them into multiple points. The workflow is something like this, right?

  Geocoding stuff --> FeatureCollection --> list of [x, y] centers --> API

What doesn't exist yet is the utility that merges the best points of interest from every address query into one feature collection. Do we want to provide such glue for users?

[perrygeo]

utility that merges the best points of interest from every address query into one feature collection

It's a bit funky but cat, jq and fio collect can already do that:

cat <(x-mapbox geocoding "Portland, OR" | jq -c .features[0]) \
    <(x-mapbox geocoding "Bend, OR" | jq -c .features[0]) \
    <(x-mapbox geocoding "Corvallis, OR" | jq -c .features[0]) \
    | fio collect > points_featurecollection.geojson

[sgillies]

Your bash fu is strong, @perrygeo.

[perrygeo]

So the current supported input options are:

• Coordinate pair(s) of the form [0, 0] or 0,0 or 0 0
• An input stream/file(s) containing either a GeoJSON Feature or FeatureCollection.
• For functions that accept points only, any non-point feature is silently filtered out.

[perrygeo]

Calling it good for now