<\/HEAD>
Esta é a primeira parte de uma série em dois capítulos sobre os riscos para os usuários de software devido à documentação deficiente; especificamente, a confusão e os resultados inesperados que surgem de operadores espaciais mal documentados em software GIS. A primeira parte da série<\/STRONG> analisa como a documentação inconsistente e incompleta exige que os usuários adivinhem como os operadores espaciais são implementados. A segunda parte da série <\/A>analisa os resultados inconsistentes que surgem da mistura de diferentes implementações de operadores espaciais.<\/EM><\/P><\/P>
Nove meses desde meu último post no blog, não posso dizer que esse foi o ritmo que eu pretendia quando o GeoNet foi criado (pelo menos não dou mais peso às resoluções do GeoNet do que às de Ano Novo<\/EM>). Não sei se minha seca acabou, mas um nervo exposto foi atingido com força suficiente pela Esri para fazer chover, pelo menos por enquanto. De todos os palanques que entulham meus armários, a documentação ruim e suas consequências é um dos mais desgastados. Por mais que Honest Abe diga que você não pode confiar em tudo que lê na internet, eu realmente acho que os usuários de software deveriam poder confiar na ajuda online\/documentação de uma empresa.<\/P><\/P>Não se pode passar muito tempo no mundo das relações espaciais sem encontrar o Modelo de Interseção 9 Estendido Dimensionalmente (DE-9IM). O DE-9IM foi desenvolvido por Clementini e outros em meados dos anos 90 como uma evolução do Modelo de 4 Interseções (4IM) e do Modelo de 9 Interseções (9IM). Embora o DE-9IM não seja a única definição de relações espaciais, tornou-se a definição 2D predominante após sua inclusão na
Especificação de Implementação OpenGIS para Informação Geográfica - Acesso a feições simples - Parte 1: Arquitetura comum<\/A>.<\/P><\/P>
Referências e discussões sobre o DE-9IM costumavam ser encontradas em várias documentações da Esri, mas essas referências e documentações estão se tornando mais difíceis de encontrar na documentação atual do ArcGIS. Por exemplo, entre os novos sites 10.3 do
ArcGIS for Desktop<\/A>, ArcGIS for Server<\/A> e ArcGIS for Developers <\/A>, Clementini é referenciado apenas em algumas poucas páginas e o DE-9IM é referenciado e discutido em apenas uma página: Funções relacionais para ST_Geometry<\/A>. Enquanto Python tem uma filosofia de "somos todos adultos", a Esri parece estar indo na direção oposta e nos alimentando com papinha, sem a fortificação vitamínica.<\/P><\/P>
Embora o DE-9IM seja a base para predicados\relações espaciais 2D em muitas bibliotecas de geometria e aplicações geoespaciais, existem dois tipos de sobreposição para a ferramenta
Selecionar Camada por Localização <\/A> onde a implementação padrão da Esri difere da Clementini: Contém, Dentro. Em ambos os casos, o tipo de sobreposição padrão ou não qualificado implica a definição da Esri (sublinhado azul<\/SPAN>) enquanto a definição Clementini (sublinhado vermelho<\/SPAN>) é tratada por meio de qualificadores.<\/P>
<\/P>Então, como a definição da Esri para Contém e Dentro difere da definição Clementini? Abrindo mão da notação matemática e das matrizes ilustrativas, a diferença se resume à forma como as fronteiras das geometrias são tratadas. Por exemplo, uma geometria a<\/SPAN> que está inteiramente na fronteira da geometria b<\/SPAN> é considerada dentro da geometria b<\/SPAN> usando a definição da Esri mas não dentro da geometria b<\/SPAN> usando a definição Clementini. Vamos criar feições simples de polígono e linha para demonstrar:<\/P><\/P>>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> arcpy.CopyFeatures_management(polygon, 'in_memory\/polygon')
<Result 'in_memory\\polygon'>
>>> arcpy.CopyFeatures_management(line, 'in_memory\/line')
<Result 'in_memory\\line'><\/PRE><\/P><\/P>
<\/P>Executando a ferramenta Selecionar Camada por Localização <\/A> usando ambas as definições de Dentro:<\/P><\/P>
>>> arcpy.SelectLayerByLocation_management("line", "WITHIN", "polygon")
<Result 'line'>
>>> arcpy.GetCount_management("line")
<Result '1'>
>>> arcpy.SelectLayerByLocation_management("line", "WITHIN_CLEMENTINI", "polygon")
<Result 'line'>
>>> arcpy.GetCount_management("line")
<Result '0'><\/PRE><\/P>Até agora, tudo bem. Além do fato de que as definições padrão da Esri para Contém e Dentro diferem da maioria das outras bibliotecas de geometria e aplicações geoespaciais, incluindo os padrões OGC para feições simples, pelo menos os resultados correspondem à escassa documentação disponível online.<\/P><\/P>Neste ponto, é realmente importante destacar algo que é facilmente negligenciado. As funções ST_Geometry da Esri são compatíveis com o acesso a feições simples OGC e padrões SQL, o que significa que ST_Within adere à definição Clementini e não à definição Esri.
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING(1 0, 2 0)', 0),
sde.st_geomfromtext('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))', 0))
FROM dual;
SDE.ST_WITHIN(SDE.ST_GEOMFROMTEXT('LINESTRING(10,20)',0),SDE.ST_GEOMFROMTEXT('PO
--------------------------------------------------------------------------------
Até este ponto, eu argumentaria que a documentação da Esri relacionada às relações espaciais tem sido fraca porque depende muito de inferências.& nbsp ; O usuário atento pode notar que há vários tipos Dentro no menu suspenso da ferramenta Selecionar Camada por Localização < \/a > , e o usuário inquisitivo pode ir um passo além para ler sobre tipos de sobreposição para entender as diferenças entre eles. & nbsp ; O usuário realmente atento e conhecedor pode entender que uma única linha na documentação Qual é o tipo de armazenamento ST_Geometry? < \/a > afirmando que ST_Geometry implementa a especificação SQL 3 significa que a função ST_Within adere à definição Clementini em vez da definição Esri da ferramenta Selecionar Camada por Localização < \/a > . & nbsp ; Em resumo, não há documentação que reconheça explicitamente que existem definições diferentes para certas relações espaciais dentro de várias partes do próprio software da Esri. < \/p >< p >< br \/ >< /p >< p > Confuso ainda? & nbsp ; Espere só até começarmos a explorar as Classes Geometry do ArcPy , porque a documentação vai de fraca para realmente fraca. & nbsp ; As únicas referências ao OGC na documentação das Classes Geometry do ArcPy são para as propriedades WKB e WKT , e não há referências ao DE-9IM ou Clementini. & nbsp ; Vamos dar uma olhada na documentação do método within : < /p >< p style = "padding-left:60px;">< IMG __jive_id = "99920" alt = "arcgis_103_geometry_class_within_documentation.PNG" class="image-3 jive-image" src="https://us.v-cdn.net/6038851/uploads/legacyfs/online/99920_arcgis_103_geometry_class_within_documentation.PNG" /><\/P>
Então, a geometria está dentro de outra geometria se ela estiver dentro dessa geometria. Entendi. Ah, espere, eles estão me perguntando se uma geometria está dentro de outra geometria? Embora nenhuma das ilustrações capture uma situação que diferencie as definições da Esri e Clementini, a falta de qualquer referência à OGC, DE-9IM ou Clementini faz pensar que está sendo usada a definição da Esri. Vamos verificar:<\/P>
<\/P>
>>> line.within(polygon)
False<\/PRE><\/P>Ai, isso dói. Está bem claro que há uma falta de consistência em como certos operadores espaciais são implementados em várias partes do software da Esri, mas a pior parte é que a documentação nem sequer aponta isso. Os usuários ficam para inferir, e provavelmente incorretamente às vezes, como o software funciona ao invés de serem informados sobre como ele funciona. Caveat utilitor<\/EM>.<\/P><\/BODY><\/HTML>
