If you're new to GIS, I'd like to ask you something. What is space made of? Think about it for a moment.

I imagine a variety of answers came to mind. It's a bit of a shame I can't actually hear what they were. But I suspect most of them were fairly abstract answers.

When trying to understand any object, the most effective approach is to grasp the essence of that object. Say there's some object made of iron. You may not know exactly what it's for, but it'll come in handy whenever you need something sturdy. If needed, you could even melt it down and turn it into some other iron object.

On the other hand, if you approach it abstractly—"uh... it's that thing... what was it called again...?"—it becomes very hard to figure out what that object actually is.

From the standpoint of needing to implement space, if you approach space as an abstract concept, it becomes extremely difficult to digitize. That's why, before we start working with space, we need a clear understanding of what space is made of.

Space is made up of three things: Points, Lines, and Polygons.

• Placing a single point in space creates a point.
• Placing countless points one after another creates a line.
• Drawing countless lines one after another creates a polygon (face).
• Combining polygons creates a space.

From a 3D perspective, more complex factors come into play, but in 2D, a complete space can be built from nothing more than points, lines, and polygons. A polygon can be expressed as a set of lines, and a line can be expressed as a set of points, so space can ultimately be expressed via the positions of points. Since OpenLayers, which this article will ultimately cover, is a 2D-style map, remembering this much is enough for now.

Let's compare the answer you thought of earlier about what space is made of against a set of points, and see which is easier to implement. I'd guess that expressing it as points $(x, y)$ is simpler.

• Point: made up of a single $(x, y)$.
• Line: made up of multiple $(x, y)$ values. However, the very first $(x, y)$ and the last $(x, y)$ must differ.
• Polygon: made up of multiple $(x, y)$ values. However, the very first $(x, y)$ and the last $(x, y)$ must be equal to each other.

Pay attention to the difference between lines and polygons. Both lines and polygons are made up of countless points, but the biggest distinguishing factor between the two is whether the first coordinate matches the last coordinate.

If the first coordinate and the last coordinate match, it's considered a complete polygon, and even if they look extremely close to the naked eye, if the first and last coordinates don't actually match, it's a line.

3D space is a very complex area that requires not just an academic-level understanding of GIS knowledge but also expertise in 3D programming, so it won't be covered here. Anyone aiming to develop in 3D is already operating on a level far beyond this article anyway.

We've learned that digital representations of space use point positions. But how, exactly, should this information be handled?

For points, fortunately, the data representation is clearly $(x, y)$. But once you move to lines and polygons, things get a bit more complicated. First, the amount of data grows significantly. There's also variation in how the data gets delimited.

• ${x_1}$,${y_1}$ ${x_2}$,${y_2}$ ... ${x_n}$,${y_n}$ (space-delimited)
• ${x_1}$ ${y_1}$,${x_2}$ ${y_2}$, ... ${x_n}$ ${y_n}$ (comma-delimited)

As shown above, even when expressing the same set, developers end up with a variety of representation methods. Not only does the size of a given column grow exponentially, but string operations also have to be performed. An even bigger problem is that formats aren't standardized across different data providers, so compatibility remains just wishful thinking.

Because of this, several formats have been devised for handling geospatial information.

The most representative geospatial data format. It's a format devised by ESRI in the United States for geospatial data. ESRI is also the company behind not just SHP but the outstanding open-source GIS tool QGIS.

SHP stores regular data columns according to their data type (VARCHAR, NUMBER, DATE, etc.) and stores only location information in a fixed spec. From this binary, you can derive both the data format and the coordinate data.

An SHP file is basically composed of the following four files. Aside from the shp file itself, the remaining files are auxiliary files that support the shp file—there's no issue working with the shp file even without them.

• shp: vector shape data (core)
• shx: vector shape index
• dbf: attribute data for each shape
• prj: coordinate reference information

Not only can it easily store various supplementary data alongside geospatial data, its structure is also very similar to a database—an advantage—and nearly every GIS tool supports SHP.

Thanks to this advantage and its versatility, it has become the standard for geospatial data, and it's fair to say most geospatial information is provided in SHP by default. In other words, knowing just SHP is enough to handle geospatial data.

You know JSON, but what on earth is GeoJSON? Well, it's exactly the JSON you already know. Except it's JSON structured in a fixed way meant to express geospatial information.

GeoJSON's format looks like below.

By borrowing JSON, which is familiar to JavaScript, it's commonly used to easily call geospatial information over HTTP communication. Because of this characteristic, it tends to be used mainly for HTTP data communication rather than for the purpose of storing geospatial data.

Of course, GeoJSON has no trouble storing geospatial data either, and well-known GIS tools support GeoJSON. It also has the advantage, unlike SHP, of not requiring any special tools to perform CRUD on the data.

JSON
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "buld_test.56",
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              14134175.8064104,
              4517568.65467798
            ],
            [
              14134176.63665842,
              4517562.01269381
            ],
            [
              14134187.59593229,
              4517562.34479301
            ],
            [
              14134175.8064104,
              4517568.65467798
            ]
          ]
        ]
      },
      "geometry_name": "SHAPE",
      "properties": {
        "name": "test",
        "address": "Somewhere in Seoul",
        "reg_date": null
      }
    }
  ],
  "totalFeatures": 1,
  "numberMatched": 1,
  "numberReturned": 1,
  "timeStamp": "2023-03-08T14:19:49.134Z",
  "crs": {
    "type": "name",
    "properties": {
      "name": "urn:ogc:def:crs:EPSG::3857"
    }
  }
}

An example of GeoJSON. coordinates carries the geospatial data.

GML (Geography Markup Language) is an XML-based geospatial data format. Before JSON grew popular, exchanging complex objects would have been quite difficult. This is a data format based on XML meant for complex data like geospatial information.

XML
<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:TEST="test"
  xmlns:wfs="http://www.opengis.net/wfs/2.0"
  xmlns:gml="http://www.opengis.net/gml/3.2"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  numberMatched="1"
  numberReturned="1"
  timeStamp="2023-03-08T14:20:58.669Z"
  xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://api.itcode.dev/geoserver/schemas/wfs/2.0/wfs.xsd test http://api.itcode.dev/geoserver/wfs?service=WFS&amp;version=2.0.0&amp;request=DescribeFeatureType&amp;typeName=TEST%3Abuld_test http://www.opengis.net/gml/3.2 http://api.itcode.dev/geoserver/schemas/gml/3.2.1/gml.xsd"
>
  <wfs:member>
    <TEST:buld_test gml:id="buld_test.56">
      <gml:name>test</gml:name>
      <TEST:SHAPE>
        <gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#3857" srsDimension="2" gml:id="buld_test.56.SHAPE">
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList>1.41341758064104E7 4517568.65467798 1.413417663665842E7 4517562.01269381 1.413418759593229E7 4517562.34479301 1.41341758064104E7 4517568.65467798</gml:posList>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </TEST:SHAPE>
      <TEST:address>Somewhere in Seoul</TEST:address>
    </TEST:buld_test>
  </wfs:member>
</wfs:FeatureCollection>

As is typical of XML, the way each piece of data is separated ends up quite verbose, so readability isn't great.

Similarly to GML, there's also a data format called KML. No, it's not "K-GML" or anything like that.

KML (Keyhole Markup Language) is a data format adapted by Google for use in Google Earth.

When extracting data from Google Earth, it's provided as KML, which is convenient not only for 2D maps but also for displaying 3D data using Google Earth.

XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<kml
  xmlns="http://www.opengis.net/kml/2.2"
  xmlns:ns2="http://www.google.com/kml/ext/2.2"
  xmlns:ns3="http://www.w3.org/2005/Atom"
  xmlns:ns4="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"
>
  <Document>
    <Schema name="buld_test_1" id="buld_test_1">
      <SimpleField type="string" name="name"/>
      <SimpleField type="string" name="address"/>
      <SimpleField type="string" name="reg_date"/>
    </Schema>
    <Folder>
      <name>buld_test</name>
      <Placemark id="buld_test.56">
        <ExtendedData>
          <SchemaData schemaUrl="#buld_test_1">
            <SimpleData name="name">test</SimpleData>
            <SimpleData name="address">Somewhere in Seoul</SimpleData>
          </SchemaData>
        </ExtendedData>
        <Polygon>
          <outerBoundaryIs>
            <LinearRing>
              <tessellate>1</tessellate>
              <coordinates>126.96946155330825,37.560818684658145 126.9694690115531,37.560771387037555 126.96956746038528,37.56077375191923 126.96946155330825,37.560818684658145</coordinates>
            </LinearRing>
          </outerBoundaryIs>
        </Polygon>
      </Placemark>
    </Folder>
  </Document>
</kml>

Aside from these, plain text-based files like CSV, Excel, and txt are sometimes used as well. However, these formats aren't well-suited for storing geospatial data, so they tend to be used in a limited way—mainly as output from extracting spatial data, or for point data only.

Just keep in mind that handling geospatial information isn't necessarily limited to SHP or GeoJSON.

• Building data by road-name address (login required)

The URL above lets you obtain building data based on road-name addresses. It provides not just buildings but a variety of data, such as provinces/cities, districts, building entrances/exits, roads, and more. Note that most of it is provided as SHP.