Firstly, that's a bad way to store coordinates as the direction to the next vertex is only assumed by the order. Also having the same delimiter to separate coordinates makes it difficult to unpack (20,30,22,32,21,31 is much more easily unpacked and readable as 20,30;22,32;21,31). Even better would be a single row for each coordinate, with a column specifying its drawing order and what feature it belongs to (this is the format it was necessary to convert the spreadsheet to).
Station Name / Order / coords
Las Vegas / 1 / 22.14,34.67
Las Vegas / 2 / 24.14,36.67
Las Vegas / 3 / 28.14,38.57
Las Vegas / 4 / 23.14,34.17
New York / 1 / 32.65,54.65
New York / 2 / 33.65,52.65
I needed to run some Python code to sort it this way - if you need to do this often I can talk you through the code, otherwise I've attached a spreadsheet in the needed format.
The reason we need it this way is because my workflow is to create a polyline boundary using the Points To Line—Data Management toolbox | Documentation tool and then the Feature To Polygon—Help | ArcGIS for Desktop tool to basically fill inside that boundary and create a polygon (complex shapes with holes etc could mess this up).
First step is also to turn that table into a point feature class, ensuring that our projection is correct.
then:
Points to Line:
PointsToLine(Input_Features, Output_Feature_Class, {Line_Field}, {Sort_Field}, {Close_Line})
(all of your points regardless of station / output path / the field which identifies your station e.g. station name or ID / the order field which lets arcmap know how to connect the dots / close-line ticked adds an extra vertex to the start/end which will help us in the next step)
then:
FeatureToPolygon_management (in_features, out_feature_class, {cluster_tolerance}, {attributes}, {label_features})
this is an easy one - set the previous output line feature class as the input, then specify the path for your output polygon feature class, defaults should be fine)
Hope this gives you an understanding.
