Conversão de ficheiros

Conversor GeoJSON pronto para EUDR

Pontos de folha de cálculo ou contornos KML/KMZ à entrada, uma FeatureCollection Tipo II à saída. Validado face aos requisitos técnicos de formato EUDR — não é um depósito TRACES nem um certificado de desflorestação zero.

Sem conta no uploader público. Convidado: cinco conversões e 250 MB por dia. Business desde 0,80 €/GB em OST → PST.

Fale com a IA — ela responde
IACOPO

Diga o que pretende obter e continue para converter.

O que esta conversão faz

CSV e XLSX tornam-se entidades Point. Os contornos vêm de KML, KMZ ou GeoJSON. O .xls antigo não é aceite — grave como .xlsx ou .csv. A saída é um ZIP com eudr-valid.geojson, errors.csv e um relatório de validação versionado.

ProducerCountry é obrigatório (ISO 3166-1 alpha-2, mais XK para o Kosovo como extensão Densem, não verificada no TRACES). Indique-o no ficheiro ou nesta página / producer_country:CI na intenção. É uma asserção e um recurso se o ficheiro não tiver país; um país diferente no ficheiro é rejeitado e nunca substituído. As coordenadas ficam em graus decimais WGS84. Não reprojetamos Lambert-93 nem Web Mercator.

Regras Tipo II que verificamos

A regra de 4 ha num Point depende da commodity: cattle / bovins / bovine ignora-a; cacau, café, madeira, soja, borracha ou palma rejeita Points acima de 4 ha. Se o Point ultrapassar 4 ha sem commodity, a conversão não passa. Com cattle, Polygon e MultiPolygon são rejeitados; os estabelecimentos bovinos são pontos. Sem commodity, Polygon e MultiPolygon são rejeitados. Uma coluna cattle na folha é ignorada e nunca é escrita no GeoJSON. Area em falta é um aviso, nunca 4 ha por omissão. ProductionPlace permanece opcional. Os polígonos devem estar fechados, sem buracos nem autointerseções. Geometrias que colapsam a 6 casas decimais são rejeitadas. As coordenadas são escritas com pelo menos 6 casas, com a mesma sombra de 6 casas da validação; não rejeitamos um número JSON que o Python guardou como 5.1. XK emite um aviso como extensão de código de país Densem, não uma verificação TRACES.

O GeoJSON gerado pode ter no máximo 25.000.000 bytes (a igualdade é permitida). É o máximo da Densem sobre o GeoJSON gerado, não a contabilidade completa de uma declaração de diligência. Não dividimos ficheiros. Um CSV separado por ponto e vírgula ou tabulação usa a vírgula decimal (0,125). Um CSV separado por vírgulas continua a rejeitar 1,234 como milhares ambíguos. Propriedades extra desconhecidas do Tipo II, como plot_id, são conservadas. Area escrita como texto em GeoJSON ou numa célula de texto Excel é convertida em número. Fechar um anel aberto também é reparado.

Onde o ficheiro é processado

O envio é convertido num worker isolado e depois oferecido para descarregar. Os ficheiros de convidado seguem a mesma retenção das outras conversões Densem e são depois eliminados. Coordenadas e nomes de produtores não são escritos nos registos da aplicação.

É a mesma conta e as mesmas quotas das outras tarefas Convert. Não existe uma subscrição EUDR separada.

Perguntas

Isto submete uma declaração de diligência no TRACES?

Não. Produz GeoJSON pronto para EUDR validado face ao formato técnico. O depósito no sistema de informação continua a ser seu.

Posso enviar um shapefile ou um livro .xls?

Não nesta versão. Use CSV ou XLSX para pontos, ou KML/KMZ/GeoJSON para polígonos. Grave primeiro o .xls antigo como .xlsx.

Como indico a commodity e o país produtor?

Use os controlos de mercadoria e país produtor, ou adicione commodity:cattle / commodity:non-cattle e producer_country:CI à intenção. Cacau, café, madeira, soja, borracha e palma correspondem a non-cattle. Um país nesta página é asserção e recurso, nunca substituição. Pode continuar a colocar country / country_code / ProducerCountry em cada entidade (incluindo ExtendedData KML).

E se algumas linhas falharem?

As entidades válidas vão para eudr-valid.geojson. As linhas rejeitadas figuram em errors.csv. Se nenhuma for válida, a conversão falha e nada é apresentado como importável.