Przenoszenie funkcji z wersji 3 do punktu końcowego SearchDestinations

Deweloperzy z Europejskiego Obszaru Gospodarczego (EOG)

Te funkcje w Geocoding API v3 zostaną zastąpione przez punkt końcowy SearchDestinations w Geocoding API v4:

  • Wejścia
  • Punkty nawigacyjne
  • Tworzenie konspektów
  • Tereny posiadłości

Jeśli do obsługi powyższych funkcji używasz interfejsu Geocoding API w wersji 3, zapoznaj się z tym dokumentem, aby dowiedzieć się, jak zamiast niego używać punktu końcowego SearchDestinations. Z tego dokumentu dowiesz się, gdzie w odpowiedzi interfejsu SearchDestinations API można znaleźć te funkcje, oraz poznasz różnice w sposobie ich reprezentowania w odpowiedziach interfejsu API między interfejsem Geocoding API w wersji 3 a punktem końcowym SearchDestinations interfejsu Geocoding API w wersji 4.

Wejścia

Aby uzyskać informacje o wejściach powiązanych z destination, użyj pola destination.entrances.

Pamiętaj, że format entrance różni się nieco od formatu wejścia w interfejsie Geocoding API w wersji 3. Każdy wpis w destination.entrances ma te pola:

  • displayName – to nowe pole opcjonalne, które będzie zawierać czytelną dla użytkownika nazwę wejścia, np. „Brama B”.
  • location – jest to lokalizacja typu LatLng, która różni się od formatu używanego w interfejsie Geocoding API w wersji 3.
  • tags – to pole jest takie samo jak pole tags w przypadku wejść z interfejsu Geocoding API w wersji 3.
  • place – analogiczne do pola buildingPlaceId w przypadku wejść z interfejsu Geocoding API w wersji 3. Identyfikator miejsca w tym polu może jednak dotyczyć miejsca dowolnego typu, nie tylko budynku.

Aby uzyskać punkty nawigacyjne powiązane z destination, użyj pola destination.navigationPoints.

Pamiętaj, że format a navigationPoint nieco różni się od formatu punktu nawigacyjnego w interfejsie Geocoding API w wersji 3. Każdy punkt nawigacyjny w destination.navigationPoints ma te pola:

  • displayName – to nowe pole opcjonalne, które będzie zawierać czytelną dla użytkownika nazwę punktu nawigacyjnego, np. „5th Ave”.
  • location – jest to lokalizacja typu LatLng, która różni się od formatu używanego w interfejsie Geocoding API w wersji 3.
  • travelModes – jest to podobne do pola restrictedTravelModes punktów nawigacyjnych z interfejsu Geocoding API w wersji 3. Możliwe wartości wyliczenia są takie same. Jedyna różnica polega na tym, że to pole reprezentuje teraz dopuszczalne środki transportu dla punktu nawigacyjnego, a nie środki transportu z ograniczeniami.
  • usage – to nowe pole zawiera przypadki użycia obsługiwane przez punkt nawigacyjny. Pamiętaj, że większość punktów nawigacyjnych ma UNKNOWN, ale nie oznacza to, że ich użycie jest w jakikolwiek sposób ograniczone.

Tworzenie konspektów

Aby uzyskać kontury budynków powiązane z destination, użyj pola displayPolygon obiektów placeView w destination, które reprezentują budynki. W przypadku każdego placeView możesz sprawdzić, czy jest to budynek z polem placeView.structureType. Jeśli typ struktury to BUILDING, kontur możesz uzyskać z pola placeView.displayPolygon. placeView będzie też zawierać dodatkowe pola dotyczące budynku, których nie było w interfejsie Geocoding API w wersji 3.

destination może mieć obiekt placeView, który reprezentuje budynek w tych polach:

  • destination.primary – to główne miejsce docelowe.
  • destination.containingPlaces – jest to pole powtarzane, które może zawierać większe miejsca, które „zawierają” miejsce podstawowe. Jeśli na przykład głównym miejscem jest subpremise, containingPlaces zwykle zawiera placeView reprezentujące budynek.
  • destination.subDestinations – jest to pole powtarzane, które może zawierać podmiejsca docelowe miejsca głównego. Na przykład poszczególne mieszkania w budynku. To pole zwykle nie zawiera symbolu placeView reprezentującego budynek.

Pamiętaj, że format placeView.displayPolygon jest zgodny z formatem konturu budynku w interfejsie Geocoding API w wersji 3, czyli formatem GeoJSON, który korzysta z formatu RFC 7946.

Tereny posiadłości

Podobnie jak w przypadku konturów budynków, aby uzyskać tereny powiązane z destination, użyj pola displayPolygon obiektów placeView w destination, które reprezentują tereny. W przypadku każdego placeView możesz sprawdzić, czy jest to podstawa, korzystając z pola placeView.structureType. Jeśli typ struktury to GROUNDS, możesz pobrać konspekt z pola placeView.displayPolygon. placeView będzie też zawierać dodatkowe pola dotyczące powodów, których nie było w interfejsie Geocoding API w wersji 3.

destination może zawierać obiekt placeView, który reprezentuje podstawy w tych polach:

  • destination.primary
  • destination.containingPlaces
  • destination.subDestinations

Pamiętaj, że format placeView.displayPolygon jest zgodny z formatem konturów terenu w interfejsie Geocoding API w wersji 3, czyli formatem GeoJSON, który korzysta z formatu RFC 7946.

Użyj maski pola, aby poprosić o te funkcje

Punkt końcowy SearchDestinations wymaga maski pola, co zostało wyjaśnione w sekcji Wybieranie pól do zwrócenia. Maskę pola można ustawić na *, aby zwrócić wszystkie pola, lub na konkretne pola, które chcesz otrzymać. Na przykład to żądanie API ustawia maskę pola, aby otrzymać wszystkie pola wymagane do uzyskania wejść, punktów nawigacyjnych, obrysów budynków i terenów miejsca docelowego:

curl -X POST -d '{"place": "places/ChIJG3kh4hq6j4AR_XuFQnV0_t8"}' \
  -H "X-Goog-Api-Key: API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Goog-FieldMask: destinations.entrances,destinations.navigationPoints,destinations.primary,destinations.containingPlaces,destinations.subDestinations" \
  https://geocode.googleapis.com/v4alpha/geocode/destinations