Kompletność po ekstrakcji

ulica             487 / 487  100,00%  ████████████████████
powierzchnia      487 / 487  100,00%  ████████████████████
nazwa lokalu      354 / 487   72,69%  ███████████████░░░░░
budynek            20 / 487    4,11%  █░░░░░░░░░░░░░░░░░░░
działka             1 / 487    0,21%  ░░░░░░░░░░░░░░░░░░░░
obręb               1 / 487    0,21%  ░░░░░░░░░░░░░░░░░░░░

129 / 487 (26,49%) bez numeru budynku ani nazwy lokalu

16 / 487 (3,29%) ma jednocześnie nazwę lokalu i numer budynku

Geokodowanie: wynik realny, ale nie pełny

MSIP jest dokładniejszy, ale działa tylko tam, gdzie mamy numer budynku:

• 20 rekordów JSON miało co najmniej jeden numer budynku,
• te rekordy zawierały łącznie 23 adresy z numerem budynku,
• 23 / 23 adresy dostały jednoznaczny punkt adresowy.

Wyniki Google odrzucano, gdy:

• Google zwracał samą ulicę,
• wynik był przybliżony,
• adres był na innej ulicy niż rekord.

Wiele adresów

MSIP znalazł wszystkie adresy z numerem budynku.

W takich przypadkach geometria powinna być wielopunktowa, a nie arbitralnie sprowadzona do jednego punktu.

Lepszy model danych: ogródek może mieć tablicę adresów i punktów adresowych.

Jak wygląda endpoint API obecnie

Endpoint:

GET https://zdmk-og-app.vercel.app/api/ogrodki

Zwraca tablicę rekordów o takim schemacie:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": {
      "type": "integer"
    },
    "idDecyzji": {
      "type": "integer"
    },
    "numerDecyzji": {
      "type": "string"
    },
    "dataRozp": {
      "type": "string",
      "format": "date"
    },
    "dataZak": {
      "type": "string",
      "format": "date"
    },
    "kategoria": {
      "type": "string"
    },
    "lokalizacja": {
      "type": "string"
    },
    "opis": {
      "type": "string"
    }
  },
  "required": [
    "id",
    "idDecyzji",
    "numerDecyzji",
    "dataRozp",
    "dataZak",
    "kategoria",
    "lokalizacja",
    "opis"
  ],
  "additionalProperties": false
}

Jak powinien wyglądać rekord API

Docelowy schemat rekordu:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": {
      "type": "integer"
    },
    "decyzja": {
      "type": "object",
      "properties": {
        "id": {
          "type": "integer"
        },
        "numer": {
          "type": "string"
        },
        "dataRozpoczecia": {
          "type": "string",
          "format": "date"
        },
        "dataZakonczenia": {
          "type": "string",
          "format": "date"
        }
      },
      "required": [
        "id",
        "numer",
        "dataRozpoczecia",
        "dataZakonczenia"
      ],
      "additionalProperties": false
    },
    "kategoria": {
      "type": "string"
    },
    "lokal": {
      "type": "object",
      "properties": {
        "nazwa": {
          "type": ["string", "null"]
        }
      },
      "required": [
        "nazwa"
      ],
      "additionalProperties": false
    },
    "adresy": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "ulica": {
            "type": "string"
          },
          "numerBudynku": {
            "type": ["string", "null"]
          },
          "numerDzialki": {
            "type": ["string", "null"]
          },
          "obreb": {
            "type": ["string", "null"]
          }
        },
        "required": [
          "ulica",
          "numerBudynku",
          "numerDzialki",
          "obreb"
        ],
        "additionalProperties": false
      }
    },
    "geolokacja": {
      "type": "object",
      "properties": {
        "zrodlo": {
          "type": ["string", "null"]
        },
        "lat": {
          "type": ["number", "null"]
        },
        "lng": {
          "type": ["number", "null"]
        },
        "geometria": {
          "type": ["object", "null"]
        }
      },
      "required": [
        "zrodlo",
        "lat",
        "lng",
        "geometria"
      ],
      "additionalProperties": false
    },
    "powierzchniaM2": {
      "type": "number"
    },
    "opis": {
      "type": "string"
    }
  },
  "required": [
    "id",
    "decyzja",
    "kategoria",
    "lokal",
    "adresy",
    "geolokacja",
    "powierzchniaM2",
    "opis"
  ],
  "additionalProperties": false
}

Najważniejsza zasada: opis zostaje, ale nie zastępuje pól strukturalnych.

Co urząd powinien poprawić

1. Dodać strukturalne pola

Minimum:

• id
• decyzja.id
• decyzja.numer
• decyzja.dataRozpoczecia
• decyzja.dataZakonczenia
• kategoria
• lokal.nazwa
• adresy[]
• adresy[].ulica
• adresy[].numerBudynku
• adresy[].numerDzialki
• adresy[].obreb
• geolokacja.zrodlo
• geolokacja.lat, geolokacja.lng
• geolokacja.geometria
• powierzchniaM2
• opis

Co urząd powinien poprawić

2. Oddzielić adres od komentarza

Zamiast:

Mogilska ( od Jana Pawła II do Ronda Mogilskiego)

Lepiej:

• ulica: Mogilska
• opis: od Jana Pawła II do Ronda Mogilskiego

Nie dodajemy osobnych pól na takie dopiski.

Pole adresowe zawiera adres, a opis zawiera doprecyzowanie.

Co urząd powinien poprawić

3. Dodać adresy, punkty adresowe albo działki i uzupełnić nazwy lokali

Obecnie:

• numer budynku: 20 / 487
• numer działki: 1 / 487
• obręb: 1 / 487
• nazwa lokalu: 354 / 487

To za mało do pewnego położenia na mapie.

Jeśli ogródek jest przy budynku: jeden lub więcej punktów adresowych.

Jeśli nie jest przy budynku: działka albo geometria.

Co urząd powinien poprawić

4. Publikować geometrię, nie tylko opis

Najlepszy model:

• punkt orientacyjny dla mapy,
• opcjonalnie poligon ogródka,
• powierzchnia w m² jako liczba.

Dlaczego: ogródek gastronomiczny jest obiektem przestrzennym, więc powinien mieć dane przestrzenne.

Co urząd powinien poprawić

5. Udostępniać dane historyczne

Dane nie powinny pokazywać tylko aktualnego stanu.

Użytkownik powinien móc sprawdzić:

• gdzie były ogródki rok temu,
• jak zmieniała się liczba ogródków w czasie,
• które miejsca pojawiają się sezonowo,
• jak wyglądała sytuacja 2, 5 albo 10 lat temu.

Dlaczego: bez historii dane są tylko bieżącą listą. Z historią stają się podstawą do analiz miasta.

Dlaczego to ważne

Lepsza struktura danych oznacza:

• mniej ręcznego czyszczenia,
• mniej błędów geokodowania,
• łatwiejsze kontrole urzędowe,
• łatwiejszą publikację mapy,
• większą przejrzystość dla mieszkańców,
• możliwość porównań między latami.

To nie jest kosmetyka. To decyduje, czy dane są tylko dokumentacją, czy realnym zasobem publicznym.