Update spatial_relationships_exercises.rst

[grolls23]

I've updated the answer key to use Multilinestring instead of Linestring in the query identifying which streets Atlantic Commons joins with, and updated the answer key to include S. Oxford Street.

The existing answer key says moving from Multilinestring to Linestring saves keystrokes and that both methods describe the same shape but this isn't true, which is evident because the Linestring representation of Atlantic Commons doesn't join with South Oxford Street. Although the note above says we can no longer use ST_Touches(), ST_DWithin also provides incorrect results with the 0.1m buffer.

I think keeping the Multilinestring Representation is preferable, at least for this question.

[pramsey]

I prefered stripping off the extra precision, for ease of eyeballing.

[dr-jts]

I agree with this change. A likely usage scenario is that the user would just cut-n-paste the geometry from the first query into the second. So the format & precision of the geometry don't really matter - the key aspect is that it is the identical geometry returned from the query.

If this change is made then the following note should be changed as well.

[robe2]

I agree with this change. A likely usage scenario is that the user would just cut-n-paste the geometry from the first query into the second. So the format & precision of the geometry don't really matter - the key aspect is that it is the identical geometry returned from the query.

If this change is made then the following note should be changed as well.

What if we apply a max_degitis arg ST_AsText to the prior example, so that shortens it a bit. https://postgis.net/docs/ST_AsText.html That would serve the purpose of getting rid of all those extra decimals nobody needs and shorten the output.

e.g.

SELECT ST_AsText(geom, 0)
  FROM nyc_streets
  WHERE name = 'Atlantic Commons';

will result in:

MULTILINESTRING((586782 4504202,586864 4504216))

Granted we'd still have the annoying MULTILINESTRING thing, but it's a bit less annoying.