De KML para GeoJSON EUDR pronto para o TRACES — sem rejeições

Por que o TRACES rejeita KML

O sistema de informação da UE espera um FeatureCollection GeoJSON em WGS84 (longitude, latitude). Uma exportação KML carrega as formas certas, mas o contêiner errado, a ordem de coordenadas incorreta em alguns pontos, valores de altitude e, muitas vezes, polígonos não fechados — cada um deles uma causa de rejeição documentada.

O DDSpass converte o KML para GeoJSON e corrige esses problemas: fecha os anéis, remove a altitude, padroniza o código do país e sinaliza tudo o que uma pessoa precise revisar.

Como converter

Solte seu .kml (ou um KMZ descompactado para KML) na ferramenta. Você recebe um GeoJSON limpo e pronto para o TRACES, além de um relatório de correções em linguagem simples que pode enviar de volta ao seu fornecedor. Tudo roda no seu navegador — o arquivo nunca é enviado.

KMZ é um KML compactado, não um segundo formato

O Salvar lugar como do Google Earth grava .kmz por padrão, então o arquivo que a maioria dos fornecedores realmente envia é um KMZ. Ele não é um formato diferente: é um pacote zip que guarda o doc.kml mais os ícones ou imagens que o marcador usava. O TRACES não aceita nenhuma das duas extensões — só .geojson e .json podem sequer ser selecionados.

Solte o .kmz do jeito que ele está. O DDSpass abre o pacote, lê o doc.kml (ou qualquer .kml que esteja lá dentro) e converte esse conteúdo — sem descompactar nada na mão. Se o pacote não tiver nenhum KML, você recebe um bloqueio claro em vez de um arquivo de saída vazio.

As pastas também vêm junto. Arquivos do Google Earth organizados com uma pasta por comunidade, cooperativa ou dia de levantamento são achatados em um único FeatureCollection, porque é essa a estrutura que a importação espera. Nomes de pasta não fazem parte do conjunto de propriedades da EUDR, então o produtor e o local precisam estar nas propriedades de cada marcador, e não na árvore de pastas.

O que um arquivo do Google Earth carrega e o TRACES não lê

As posições em KML são escritas como longitude,latitude,altitude — três valores, e o Google Earth grava o terceiro mesmo quando ele é zero. A geolocalização EUDR é bidimensional, então a altitude não significa nada para a declaração. O DDSpass a descarta e mantém o par longitude/latitude em graus decimais WGS84, que é a ordem de coordenadas usada pelo GeoJSON.

URLs de estilo, definições de ícone e de cor e o balão de descrição em HTML são simplesmente ignorados: o TRACES lê um conjunto exato de nomes de propriedade, sensível a maiúsculas e minúsculas. O name de um marcador não é o ProductionPlace, então confira se estes quatro existem e estão escritos exatamente assim. O DDSpass preenche um local de produção ausente com um identificador numerado e sinaliza um país ausente ou fora do padrão ISO2 para o fornecedor responder.

• ProducerName — quem produziu a commodity
• ProducerCountry — país de produção como código ISO2 (UK é convertido para GB, e EL para GR)
• ProductionPlace — a parcela ou a descrição do local
• Area — hectares, como número, nunca como texto

Um caminho desenhado não é o limite da parcela

No Google Earth, Adicionar › Polígono e Adicionar › Caminho ficam quase idênticos na tela e são exportados de formas completamente diferentes. Um caminho vira um <LineString> do KML, e LineString e MultiLineString não são geometrias aceitas na EUDR — os tipos permitidos são Point, MultiPoint, Polygon e MultiPolygon.

Se o caminho foi desenhado fechado, com o último vértice caindo em cima do primeiro, ele é um limite em tudo menos no tipo, e o DDSpass o promove a Polygon. Se estiver aberto, ele é bloqueado em vez de fechado por você: unir duas pontas soltas inventaria um limite que ninguém percorreu. Redesenhe como polígono e exporte de novo.

Os polígonos de verdade exigem mais duas conferências. Todo anel precisa estar fechado — primeira posição idêntica à última, com pelo menos quatro posições — e uma parcela desenhada com um recorte para um lago, uma construção ou um trecho não plantado vira um anel interno, a única geometria que o TRACES recusa de forma visível: Polygon with holes are not accepted by the system. O DDSpass fecha os anéis abertos e remove os anéis internos com um aviso, para que você decida se aquele terreno excluído entra ou não nos hectares declarados.

Perguntas

O TRACES aceita KML para EUDR?

Não. O sistema da UE só aceita GeoJSON para a geolocalização. KML e KMZ precisam ser convertidos antes.

Os dados do meu fornecedor são enviados para algum lugar?

Não. A conversão e a validação acontecem inteiramente no seu navegador; o arquivo nunca sai do seu dispositivo.

Preciso descompactar um KMZ antes de converter?

Não. Solte o .kmz direto — ele é um zip com o doc.kml dentro, e o DDSpass o abre e lê o KML. Como o KMZ é o formato padrão de salvamento do Google Earth, esse é o caso normal, não a exceção. Se o pacote não contiver nenhum KML, você recebe um bloqueio claro em vez de um arquivo vazio.

Minhas coordenadas KML têm um terceiro valor de altitude — isso é um problema?

O KML escreve as posições como longitude, latitude, altitude, e o Google Earth inclui o terceiro valor mesmo quando ele é zero. A geolocalização EUDR é bidimensional, então a altitude não carrega significado para a declaração. Ela é descartada durante a conversão e o par longitude/latitude restante é mantido em graus decimais WGS84.

Desenhei a parcela como caminho no Google Earth, e não como polígono — vai funcionar?

Não do jeito que está. Um caminho é exportado como LineString, que não é um dos tipos de geometria aceitos (Point, MultiPoint, Polygon, MultiPolygon). Se o seu caminho estiver realmente fechado, o DDSpass o converte em Polygon; se estiver aberto, ele é bloqueado, porque fechá-lo automaticamente inventaria um limite que nunca foi levantado em campo.