2014-07-13 17 views
5

Patrzę na Chicago Open Data Portal o numerze list of bus stops i widzę, że podwójnie uniknęli niektórych, ale nie wszystkich, ich ampersandów. Innymi słowy, czasami kodują swoje ampersandy jako wzmacniacz, a czasami tak samo jak & # 38;Korzystanie z obu & i amp; reprezentować znak ampersand w KML?

Wzorzec, który widzę, polega na tym, że w podwójny sposób wychodzą z pola ampersands wewnątrz pól opisu, które są pełnoprawnymi dokumentami HTML wewnątrz dokumentu samego dokumentu KML.

Czy ktoś ma wgląd w to? Czy to błąd w danych miasta? Nie jest poprawnie renderowany również w Google Earth.

Odpowiedz

2

Kodowanie encji XML na liście przystanków w KML na liście Open Data Portal w Chicago jest nieprawidłowe.

Poniższy fragment kodu KML pojawia się jako Indiana & 14th Street w dymku z opisem w Google Earth, a nie jako "Indiana & 14th Street", co zostało zamierzone.

przykład:

<Placemark> 
    <name>Indiana &#38; 14th Street</name> 
    <description> 
     <![CDATA[<html xmlns:fo="http://www.w3.org/1999/XSL/Format"> 
     ... 
     <td>PUBLIC_NAME</td> 
     <td>Indiana &#38;amp; 14th Street</td> 
     .... 
     </html> 
     ]]> 
    </description> 

tekst &#38;amp; jest dekodowany jako &amp; który za pomocą bloku CDATA pokazano jak są. Aby wyświetlić "&" w opisie, wymagane jest &#38; lub &amp; (nie obie) w treści bloku CDATA. Kodowanie w polu nazwy jest poprawne, ponieważ nie ma znacznika CDATA.

W rzeczywistości plik KML powinien używać pojedynczego BalloonStyle do przechwytywania długiego tekstu HTML w każdym oznaczeniu miejsca z ExtendedData dla określonych wartości (np. Miasta, stanu, nazwy publicznej itp.) W oznaczeniach miejsc oraz kompresowania pliku jako KMZ - znacznie zmniejszyłoby to plik o 15 MB do znacznie mniejszego rozmiaru.

Poniżej znajduje się samouczek z wykorzystaniem BalloonStyles i ExtendedData.
https://developers.google.com/kml/documentation/extendeddata

Oto opis kodowania specjalnego encji w KML.
http://kml4earth.appspot.com/kmlErrata.html#encoding