Kortblok: Vis en placering uden at skjule adressen

En kortblok hjælper en besøgende med at forstå, hvor et fysisk sted befinder sig, og bevæge sig fra læsning til navigation. Dens varige indhold er den verificerede adresse i HTML; det visuelle kort er en valgfri orienteringshjælp. Standardimplementeringen reserverer kortområdet, viser en letvægts statisk fallback og indlæser en godkendt interaktiv udbyder først, når den besøgende beder om det.

National Gallery
Trafalgar Square, London WC2N 5DN, Storbritannien
Kort ikke indlæst. Åbn lokationen i dit korts app, eller aktiver Indlæs interaktivt kort, når du har brug for at inspicere de omkringliggende gader.

Denne gengivne facade er nyttig før nogen tredjepartsanmodning. Den navngiver stedet, viser adressen som markerbar tekst, forklarer den ikke-indlæste tilstand og giver to tydelige ruter: åbn et eksternt kort, eller indlæs bevidst det indlejrede kort.

Hvorfor dette element er vigtigt

Lokationsspørgsmål er praktiske. En besøgende kan være ved at beslutte, om en afdeling er tæt nok på, tjekke hvilken side af en jernbanelinje den ligger på, finde den korrekte indgang eller sammenligne offentlig transport med parkering. Et kort reducerer det mentale arbejde ved at oversætte en ukendt adresse til rumlig kontekst. Det kan gøre nærliggende vartegn og vejforhold synlige hurtigere end et afsnit.

Den bekvemmelighed gør ikke kortet til sandhedskilden. Besøgende kan kopiere en adresse, sende den til en anden person eller læse den med hjælpeteknologi. Kortfliser kan ikke pålideligt understøtte disse handlinger, og svage data, privatlivsindstillinger eller udbyderfejl kan blokere dem. Adressen skal forblive brugbar uden kortet.

Et indlejret kort kan tilføje en iframe, JavaScript, skrifttyper, billeder og tredjepartsanmodninger. Disse ressourcer konkurrerer med sidens svar og kan afsløre en IP-adresse eller igangsætte lagring, der kræver samtykke. En besøgende, der aldrig bruger kortet, bør ikke betale den omkostning.

Maskinudtrækbarhed betyder, at software kan identificere stedet uden at fortolke kortpixels eller eksekvere udbyderen. Søgecrawlere, AI-systemer, skærmlæsere, oversættelsesværktøjer og lokale datapipelines har brug for et stednavn, en komplet postadresse, koordinater hvor reguleret, og et stabilt destinationslink i HTML eller strukturerede felter. En iframe-URL er ikke en pålidelig adresse. Udbyderetiketter kan ændre sig, og prikker kan være en smule fejlplacerede. Den samme verificerede lokationspost bør forsyne den synlige adresse, kortmarkøren, navigationslinket og enhver berettiget struktureret data.

Element-skrivereglerne har forrang: vælg et typebestemt element efter formål, ikke udseende. Hvis formålet er rumlig orientering omkring ét verificeret sted, brug en kortblok. Hvis formålet er at offentliggøre kontaktoplysninger, brug en åbningstider og kontaktblok eller NAP-blok og lad kortet forbruge den samme adressepost. Hvis formålet er at reservere et tidspunkt, brug en bookingblok .

Hvornår skal det bruges

Brug en kortblok, når det at se stedet i dets omgivelser hjælper læseren med at fuldføre en lokationsafhængig opgave. Typiske anvendelser inkluderer en butik, et kontor, en klinik, et mødested, et afhentningssted, et showroom, et hotel, en seværdighed, en afdeling, en eventindgang eller en serviceområdegrænse. Det er især nyttigt, når indgangen adskiller sig fra postadressen, nærliggende veje er forvirrende, tilgængelighedsruter har brug for forklaring, eller offentlig transport og parkering påvirker besøget.

Bekræft markøren i forhold til den faktiske indgang eller det faktiske servicepunkt i stedet for at acceptere udbyderens første geokodningsresultat. For et sted inde i en større bygning skal du angive etage, enhed eller indgang i tekst.

Grænsetilfælde skaber ofte tiltalende, men ubrugelige kort:

• En liste over betjente byer: dette er en serviceområdeerklæring, ikke bevis på en fysisk lokation. Placer ikke prikker ved bycentre og antyd kontorer.
• En postadresse uden besøgsadgang: offentliggør postoplysningerne og angiv, at besøg ikke er mulige. Et kort ville antyde en ikke-understøttet ankomsthandling.
• En fjern- eller kun-online-virksomhed: et registreret kontor kan være juridisk relevant, men det bliver ikke en kundedestination, fordi en indlejring kan lokalisere det.
• Tur-for-tur-vejledning: link til en navigationsudbyder og giv rutespecifikke noter. Et statisk indlejret kort kan ikke tage højde for trafik, vejlukninger eller den besøgendes startpunkt.
• Mange lokationer: brug en lokationsfinder med en tekstlig resultatliste. En sky af prikker kan ikke erstatte individuelle afdelingssider.
• Bevis på lokal tilstedeværelse: et kort er ikke dokumentation for, at et team opererer der. Understøt påstanden med konsistent identitet, adresse, kontakt, åbningstider og afdelingsspecifikt indhold.
• Dekorativ geografisk kontekst: hvis lokationen ikke påvirker opgaven, udelad kortet. En bysilhuet eller regional kontur hører til et andet visuelt formål.

Hvor skal det placeres

Placer kortet umiddelbart efter stednavnet, den komplette adresse og eventuelle besøgsvigtige kvalifikation. På en lokationsside er den sædvanlige rækkefølge introduktion, adresse og kontaktfakta, kort, ankomstnoter, åbningstider, derefter besøgs- eller bookinghandlingen. Hvis kørselsvejledning er det primære svar, opsummer dem før kortet.

Hold adressen, kortfacaden, indlæsningskontrollen, fallback-linket, billedteksten og vejledningsnoten i ét markeret område. Den besøgende bør ikke skulle krydse et testimonial- eller markedsføringsafsnit for at finde adressen, der hører til prikken. Et “Få kørselsvejledning”-link skal bruge de samme koordinater eller det samme sted-id som den viste markør.

Blokken kan sidde nær åbningstider for samme afdeling, men ikke ved siden af en modstridende adresse, et andet kort, en autospillende video eller en reklame, der er stilet som en kontrol. Placer den ikke inde i en karrusel, et harmonika-element, en påkrævet modal, en skjult fane eller en smal tabelcelle.

Placer ikke kortet mellem en advarsel og den instruktion, den kvalificerer, eller mellem en bookinghandling og dens forudsætninger. Overlæg aldrig væsentlig adressetekst, samtykkeformulering eller det eneste kørselsvejledningslink på kortfliser. På mobil bevar denne læserækkefølge: stednavn, adresse, besøgskvalifikation, fallback, indlæsningskontrol, kortområde, derefter kørselsvejledning.

Anatomi

1. Stednavn: identificerer den afdeling, det mødested eller den destination, som markøren repræsenterer.
2. Komplet tekstadresse: inkluderer hver adresselinje, lokalitet, postnummer og land, der er nødvendigt for at skelne stedet.
3. Besøgskvalifikation: angiver indgang, enhed, etage, aftalekrav, besøgsrestriktion eller tilgængelighedsfakta, når det ændrer ankomsten.
4. Reserveret viewport: fastsætter bredde og billedformat, før interaktive ressourcer indlæses, hvilket forhindrer layoutændringer.
5. Statisk fallback: giver nyttig rumlig kontekst uden scripts; det skal være et reelt genereret aktiv, før det refereres.
6. Markør: repræsenterer det verificerede ankomstpunkt, ikke blot et postnummer eller administrativt centrum.
7. Indlæsningskontrol: er en rigtig knap med et specifikt tilgængeligt navn, f.eks. “Indlæs interaktivt kort for National Gallery.”
8. Udbyderbesked: navngiver tredjeparten og forklarer, at aktivering kan oprette forbindelse til den.
9. Kørselsvejledningslink: åbner en stabil HTTPS-destination til navigation uden at kræve den indlejrede spiller.
10. Billedtekst eller vartegnsnote: forklarer kortets nyttige konklusion, f.eks. at indgangen vender mod en navngiven gade.
11. Lokationspost: leverer regulerede koordinater, sted-id og verificeringsdato til gengiveren.
12. Fejltilstand: bevarer adressen, kørselsvejledningslinket og muligheden for at prøve igen, hvis udbyderen ikke kan indlæses.

Designeksempler

Hver variant holder adressen i HTML, reserverer kortets dimensioner og giver et direkte kørselsvejledningslink. Kun indlæsningsadfærden ændres.

Statisk kort med ekstern kørselsvejledning — lavest omkostning

Brug et optimeret kortbillede, når orientering hjælper, men panorering og zoom ikke gør. Alternative tekst angiver dens rumlige konklusion; billedteksten bærer vartegn. Offentliggør stien først, når aktivet eksisterer.

Klik-til-indlæs interaktivt kort — standard

Vis først en statisk fallback eller neutralt reserveret panel. En knap indlæser den godkendte iframe efter eksplicit aktivering. Dette beskytter sidehastigheden og gør tredjepartsforbindelsen bevidst, samtidig med at panorering, zoom og gadeinspektion er tilgængelig efter behov.

Samtykkestyret kort

Brug dette, når webstedets privatlivspolitik kræver samtykke, før der oprettes forbindelse til udbyderen. Forklar konsekvensen i almindeligt sprog og tilbyd kørselsvejledningslinket uden at kræve samtykke. Afvisning må ikke skjule adressen eller forhindre resten af siden i at fungere.

Altid indlæst interaktivt kort — målt undtagelse

Brug kun, når interaktion er central, udbyderkontakt er tilladt, og feltmåling accepterer omkostningen. Træg indlæsning kan stadig initialiseres, når den besøgende nærmer sig. Behold en servergengivet fallback, fordi loading="lazy" ikke kan forhindre udbyderfejl.

Enkeltlokationsblok inde i en lokalitetsfinder

Til en side med flere lokationer parres det valgte kort med en tekstlig resultatliste. Indlæsning af én valgt afdeling holder interaktionen forståelig; ændring af valg opdaterer stednavn, adresse, markør og kørselsvejledningslink samtidigt. Listen forbliver brugbar uden kortet.

Parametre

“Kilde” betyder, hvor gengiveren henter den forfattede værdi. Det autoritative lokationssystem forbliver ansvarligt for at verificere den faktiske adresse og koordinater.

Gengiveren skal opbygge udbyder-URL’er fra godkendte id’er og numeriske koordinater. Forfattere må ikke indsætte vilkårlig iframe-HTML, API-nøgler, adgangstokens eller JavaScript i brødteksten. Seks decimaler placerer et punkt med meget finere præcision, end en besøgende normalt har brug for; behold færre cifre, når offentliggørelse af en præcis privat indgang ville skabe en sikkerheds- eller privatlivsrisiko.

Syntaks og kodeeksempler

Disse bærbare eksempler beskriver én kanonisk indholdsmodel. Et projekt skal implementere og teste den tilsvarende gengiver, før forfattere bruger syntaksen i produktion.

Bærbar Markdown-direktiv

:::map{variant=facade place-id="north-street-clinic" latitude=51.454514 longitude=-2.587910 zoom=16 aspect-ratio="4/3" provider=osm directions-url="https://www.openstreetmap.org/directions?to=51.454514,-2.587910" verified=2026-08-27}
## North Street Clinic

18 North Street, Bristol BS1 3PR, United Kingdom

Use the courtyard entrance beside the pharmacy. Step-free access is available from North Street.
:::

Den første overskrift leverer title; den næste linje leverer den strukturerede adresse; og den resterende brødtekst leverer billedteksten eller ankomstnoten.

Hugo shortcode-tilknytning

Brug kun navngivne parametre. Denne notation dokumenterer den tilsigtede adapter; den hævder ikke, at en map-shortcode allerede findes i dette repository.

{{< map variant="facade" placeId="north-street-clinic" latitude="51.454514" longitude="-2.587910" zoom="16" aspectRatio="4/3" provider="osm" directionsUrl="https://www.openstreetmap.org/directions?to=51.454514,-2.587910" verified="2026-08-27" >}}
## North Street Clinic

18 North Street, Bristol BS1 3PR, United Kingdom

Use the courtyard entrance beside the pharmacy. Step-free access is available from North Street.
{{< /map >}}

Adapteren skal reservere forholdet, gengive adressen og fallback på serveren og kun oprette iframe’en efter den deklarerede udløser. Den må aldrig eksponere en udbyder-API-nøgle i forfattet indhold.

WordPress-blok

<!-- wp:amicited/map {"variant":"facade","placeId":"north-street-clinic","latitude":51.454514,"longitude":-2.587910,"zoom":16,"aspectRatio":"4/3","provider":"osm","directionsUrl":"https://www.openstreetmap.org/directions?to=51.454514,-2.587910","verified":"2026-08-27"} -->
<h2>North Street Clinic</h2>
<address>18 North Street, Bristol BS1 3PR, United Kingdom</address>
<p>Use the courtyard entrance beside the pharmacy. Step-free access is available from North Street.</p>
<!-- /wp:amicited/map -->

En indbygget blok bør gemme koordinater som tal, holde adressefelter strukturerede, validere udbyderen og gengive en sikker serverside-facade. Redigeringsforhåndsvisning kan vise en statisk repræsentation i stedet for at initialisere den fulde udbyder.

Gode og dårlige eksempler

Godt

North Street Clinic
18 North Street, Bristol BS1 3PR, United Kingdom
Use the courtyard entrance beside the pharmacy. Step-free access is available from North Street.
Indlæs interaktivt kort · Åbn kørselsvejledning i et korts app

Dette virker, fordi den besøgende kan identificere, kopiere og navigere til stedet uden indlejringen. Indgangsnoten løser en reel ankomsttvetydighed. Indlæsning af tredjeparten er et valg, og begge handlinger angiver tydeligt, hvad der sker.

Dårligt

Find os her!
[fuldbredde interaktivt kort med en umærket prik]

Dette fejler, fordi “her” ikke identificerer et sted, adressen findes kun inde i udbyderpixels, og prikken kan repræsentere et postnummer snarere end en indgang. Det ivrige kort tilføjer omkostninger selv for besøgende, der ikke bruger det. Der er ingen fallback, verificeringsdato, ankomstnote eller tilgængeligt navigationslink. At tilføje en adresse til iframe’ens title ville forbedre rammeetiketten, men ville ikke skabe markerbar sidetekst.

Skemamarkering og tilgængelighed

En kortblok har ingen dedikeret Schema.org-type. Verificerede felter kan forsyne den relevante Organization, LocalBusiness-underkategori, Place, PostalAddress eller GeoCoordinates, når siden repræsenterer den pågældende enhed. Brug én delt lokationspost; den synlige adresse, markør, kanoniske afdelings-URL og JSON-LD skal være enige.

Tilføj ikke hasMap udelukkende for at få siden til at se mere komplet ud. Når det bruges, bør det pege på en stabil kort-URL for det samme sted, ikke en udløbende sessions-URL eller et iframe-endepunkt med en eksponeret nøgle. En serviceområdevirksomhed uden en offentlig kundelokation bør beskrive sit serviceområde ærligt og må ikke offentliggøre opdigtede lokaler eller alt for præcise private koordinater.

Tilgængelighed begynder med uafhængighed af kortet. Placer stednavnet og den fulde adresse i HTML, brug <address> kun til relevant kontaktinformation. Giv et normalt kørselsvejledningslink. Beskriv indgange, vartegn, offentlig transport, parkering og niveaufri adgang i tekst. Alternativ tekst til statiske kort bør kommunikere den nyttige konklusion, ikke liste hver gade op.

Indlæsningskontrollen skal være en tastaturbetjenbar <button> med synligt fokus og et tilgængeligt navn knyttet til stedet. Indlæsning må ikke flytte fokus uventet. Efter aktivering annonceres en kort status som “Interaktivt kort indlæst,” og behold derefter fokus på den initierende kontrol, eller flyt det kun, når grænsefladen har et dokumenteret tastaturindgangspunkt. Giv hver iframe en unik titel, f.eks. “Interaktivt gadekort for North Street Clinic.”

Udbyderkontroller skal forblive betjening ved smalle bredder og 200 % zoom. Fang ikke tastaturfokus inde i iframe’en. Stol ikke på prikfarve, trækbevægelser, hover eller visuelle gadeetiketter til væsentlig information. Hvis kortet fejler, eller samtykke afvises, hold det reserverede område stabilt og eksponer adressen, ankomstnoten, det eksterne kørselsvejledningslink og muligheden for at prøve igen.

Skriveregler

Indled med det officielle offentlige stednavn på to til ti ord. Følg med den komplette postadresse som gemt i den regulerede lokationspost. Forkort ikke en enhed, bygning, lokalitet eller et postnummer, der er nødvendigt for at nå den korrekte indgang. Inkluder landet, når siden kan modtage international trafik, eller når bynavnet er tvetydigt.

Tilføj én ankomstnote på 8–35 ord kun, når den ændrer, hvad den besøgende skal gøre. Nævn et varigt vartegn eller indgangsforhold: “Brug gårdspladsindgangen ved siden af apoteket” er nyttigt; “Du kan ikke overse os” er det ikke. Tidsfølsomme vejlukninger, byggeruter og midlertidige indgange kræver en ejer og en gennemgangsdato andre steder i indholdssystemet.

Brug én kortblok til én valgt destination. En lokalitetsfinder kan skifte den destination, men hver valgt tilstand skal opdatere titlen, adressen, markøren, billedteksten og linket atomisk. Vis én primær markør som standard. Sekundære vartegn må kun vises, når de forklarer ankomst, og er visuelt adskillelige i tekst og kontroller.

Hold kontroletiketter bogstavelige: “Indlæs interaktivt kort,” “Åbn kørselsvejledning” og “Se tilgængelig indgang.” Undgå vage etiketter som “Udforsk,” “Se mere” eller “Klik her.” Angiv udbyderen før aktivering, når en forbindelse har privatlivsmæssige konsekvenser.

Placer aldrig telefonnumre, åbningstider, reklamepåstande, anmeldelser, priser, bookingsformularer eller lange parkeringspolitikker inde i det interaktive lærred. Disse fakta hører til i HTML og i deres egne typede elementer. Offentliggør aldrig en API-nøgle, en brugers live-position, en privat boligindgang, fabrikerede kontorprikker, ikke-verificerede serviceområder eller koordinater kopieret fra en ukontrolleret geokoder. Kortet må ikke antyde besøgsadgang, hvor der ikke er nogen.

Verificer adressen og markøren ved offentliggørelse, efter en placeringsændring og under planlagt gennemgang. Udbyderes veje og etiketter kan ændre sig uafhængigt; organisationen ejer stadig nøjagtigheden af sin lokationspost og ankomstinstruktioner.

Posttyper, der bruger det

Feltet postTypes i frontmatter er kilden til denne implementeringsmatrix.

QA-tjekliste

• Stednavnet og den komplette adresse fremgår som markerbar servergengivet tekst uden for kortet.
• Markøren peger på det verificerede offentlige ankomstpunkt snarere end et postnummer eller bygningscentrum.
• Adressen, koordinater, sted-id, kørselsvejledningslink og strukturerede data kommer fra den samme regulerede post.
• Blokken forklarer enhver enhed, etage, indgang, aftaleregel eller tilgængelighedsrute, der er nødvendig for at ankomme.
• Standardimplementeringen undgår tredjepartsanmodninger indtil eksplicit aktivering eller gyldigt samtykke.
• En altid-indlæst undtagelse har et dokumenteret formål, privatlivsgrundlag og målt ydelsesbudget.
• Bredde og billedformat er reserveret, før billede, iframe eller udbyderkode indlæses.
• Enhver statisk billedsti peger på et reelt godkendt aktiv og har nyttig alternativ tekst.
• Indlæsningskontrollen er en knap med et stedspecifikt tilgængeligt navn og synligt fokus.
• Iframe’en, når den oprettes, har en unik beskrivende titel og fanger ikke tastaturfokus.
• Adressen, kørselsvejledningslinket, ankomstnoten og genforsøgsstien forbliver brugbare, når scripts, samtykke eller udbyderen fejler.
• Væsentlig information afhænger ikke af prikfarve, hover, træk, zoom eller kortetiketter.
• Layoutet fungerer ved smalle bredder og 200 % zoom uden at dække udbyderkontroller.
• Siden hævder ikke et offentligt kontor, indgang eller serviceområde, som organisationen ikke kan verificere.
• Ingen API-nøgler, adgangstokens, brugerlokationer, private koordinater eller vilkårlige iframe-URL’er findes i forfattet indhold.
• Implementeringer med flere lokationer bevarer en tastaturtilgængelig tekstliste og synkroniserer den valgte afdeling atomisk.
• Skema, hvis til stede, beskriver den samme virkelige enhed og adresse, som vises for besøgende.
• Verificeringsdatoen og gennemgangsejeren opfylder webstedets vedligeholdelsespolitik for lokale data.

En kortblok lykkes, når det at miste kortet ændrer bekvemmelighed, ikke betydning. Læseren ved stadig, hvor stedet er, hvordan man når det, og hvad man kan forvente; udbyderen forbliver valgfri.