Verwijzend naar NaN of ± ∞ (speciale drijvende-kommawaarden) in query's met ArcMap-definities?

Ik heb toevallig ontdekt hoe ArcMap speciale drijvende-kommawaarden voor de gebruiker weergeeft.

  • +∞ (positive infinity) is displayed as 1.#INF
  • –∞ (negative infinity) would supposedly be displayed as -1.#INF — I haven't verified this one.
  • NaN (not a number) is displayed as a right-aligned — not to be confused with left-aligned , which denotes NULL (missing values):

    Screenshot of a table viewed in ArcMap that shows two distinct types of NULL

    (Get unique values in the field calculator does not list NaN at all, by the way.)

Maar ik heb niet ontdekt hoe ik query's voor de laagdefinitie kan schrijven om rijen te selecteren op basis van deze speciale waarden:

  • ColumnName IS NULL will only select regular NULL values, but non NaN.
  • ColumnName = 1.#INF is rejected as having invalid syntax.

Weet iemand hoe dit te doen?


C# ArcObjects-codefragment voor het opslaan van een 1. # INF-waarde voor een tabelveld (basisconcept):

Zoals gevraagd. Omdat ik niet meer op het werk ben, is het volgende niet de echte code die ik heb gebruikt en ik kan het nu niet testen, maar het moet het effect hebben dat wordt weergegeven in de bovenstaande schermafbeelding:

ITable table = …;
int doubleFieldIndex = table.FindField(…);
IRow row = table.CreateRow(); 
row.Value[doubleFieldIndex] = double.PositiveInfinity;
row.Store();
10
Wat voor soort gegevens is dit? Is dit een attributentabel van een Grid? Heeft u deze gegevens geïmporteerd uit een niet-ArcGIS-bron?
toegevoegd de auteur BIBD, de bron
@Stakx - kun je de "ArcObjects" -code plaatsen die deze nummers maakt?
toegevoegd de auteur BIBD, de bron
Delen door nul zou moeten crashen omdat het niet is toegestaan. Zal het delen van een getal met nul niet een fout veroorzaken? Ik zou een validatieroutine toevoegen en de nummers controleren voordat ik ze opsla. Welk gegevenstype is uw "drijvende-kommagetal"? Als u een VB.NET Floating-point of ander gegevenstype declareert, moet u ervoor zorgen dat het compatibel is met ESRI-gegevenstype. Het lijkt mij dat het nog steeds een kwestie kan zijn van het opslaan van een buiten het bereik of anderszins onverenigbare waarde in een "ESRI" -tabel.
toegevoegd de auteur BIBD, de bron
Ik heb net je code gezien. Het is duidelijk dat je de constante "double.PositiveInfinity" in een "dubbel" ESRI-veld kunt opslaan zonder een fout te maken. Ik betwijfel of dit is toegestaan. Ik denk dat dit kan leiden tot corruptie.
toegevoegd de auteur BIBD, de bron
@Devdatta, voor zover ik kan zien, verkrijg unieke waarden vermeldt helemaal geen NaN.
toegevoegd de auteur Ian Robinson, de bron
@Jakub: dit is een tabel in een bestands-geodatabase en de velden die worden weergegeven in de schermafbeelding hebben het type Double. En nee, de tabel is gemaakt en bewerkt met een ArcObjects & ArcMap.
toegevoegd de auteur Ian Robinson, de bron
@Jakub: als je echt geïnteresseerd bent, laat het me dan opnieuw weten, maar IMHO vereist voor deze vraag geen ArcObjects-code. Om samen te vatten: je eindigt met oneindig als je bijvoorbeeld een drijvend kommagetal met 0 deelt en het resultaat vervolgens opslaat in een tabelveld via een ICursor/IFeatureCursor. Heel duidelijk.
toegevoegd de auteur Ian Robinson, de bron
@Jakub: (Afdeling door 0 werkt anders voor gehele getallen en IEEE getallen met drijvende komma Het resultaat is niet gedefinieerd in reguliere rekenkunde, maar levert oneindig op met floating-point aritmetiek. Maar dit detail is hier grotendeels irrelevant.) Kunt u mij wijzen op de ESRI-documentatie die uitlegt hoe geodatabasen omgaan met speciale drijvende-kommawaarden?
toegevoegd de auteur Ian Robinson, de bron
@johanvdw: Ik weet hoe ik deze waarden kan elimineren. Dat is echter niet het probleem. Ik ben me ervan bewust geworden dat deze waarden kunnen in een gegevensset verschijnen en ik ben benieuwd hoe ik ze als een GIS-gebruiker (d.w.z. in ArcMap) moet aanpakken.
toegevoegd de auteur Ian Robinson, de bron
Ik heb geen toegang tot ArcGis om het in dit geval te testen, maar vaak (in verschillende softwarepakketten) kun je deze waarden verwijderen door een zoekopdracht uit te voeren zoals if (a = a, a, -9999).
toegevoegd de auteur ruds, de bron
Ja, maar hoe kreeg je zulke waarden in de velden?
toegevoegd de auteur whuber, de bron
Uitstekende vraag. Ik was me er niet van bewust dat NaN wordt weergegeven als een rechts uitgelijnde . Ik kijk ook uit naar de antwoorden. btw, Hoe ziet de uitgelijnde eruit in het venster Zoeken op kenmerk (wanneer u alle afzonderlijke waarden voor dat veld krijgt?)
toegevoegd de auteur Henrik, de bron

1 antwoord

In ArcGIS een eendimensionaal drijvende-kommagetal heeft een bereik van ongeveer -3,4E38 tot 1,2E38.

Als u daadwerkelijk de 1. # INF -1. # INF-waarden in uw attribuuttabel (of via MS Access bij het analyseren van kenmerken) of rasterstatistieken ziet, zijn dit mogelijk getallen die buiten het bereik vallen dat wordt ondersteund door ESRI. En als dit aantal inderdaad buiten het ondersteunde bereik valt, is het veilig om te zeggen dat u niet naar deze waarden kunt zoeken. Je zou meer en minder kunnen proberen dan het maximum en minimum (-3.4E38 tot 1.2E38) en zien wat het oplevert, maar ik twijfel of de vraag helemaal werkt als de tabel/het veld niet-geëxporteerde reeks waarden bevat.

This source suggests that such values might have been imported from a 3-rd party non-ESRI application. You might need to convert the values to a supported range of values prior to importing to an ESRI product.

As for the NULL/NuN values, it would be usefull to know exactly what we are looking at in your example; An attrubute table of a grid, shapefile, geodatabase feature class, etc. For example, shapefiles cannot store NULL values so if a feature class thant contains NULL values is converted to a shapefile those are stored as various other values ("",0,NuN?, etc.) but when displayed in an ArcMap attribute table they are still visually represented as "". It's possible that the alignment of the NULLs in your attribute table is a such situation. I am only speculating about why you are able to query the left aligned NULLs but not the right-aligned NULLs but if this is a shapefile, try importing into a geodatabase then run the query again. Chances are that all of these will be converted to proper NULL values.

2
toegevoegd
@stakx - Ik heb net je opmerkingen hierboven opgemerkt. Ik heb de opmerkingen niet gezien toen ik mijn antwoord formuleerde. Ik laat het hier toch achter.
toegevoegd de auteur BIBD, de bron
Eigenlijk is een shapefile één plausibele manier waarop dergelijke waarden kunnen voorkomen. Met een shapefile worden getallen gehandhaafd in het ASCII-basiskarakter van basisformaat, niet als binaire floats of doubles. Als de opgeslagen waarde wordt geconverteerd naar een oneindig of NaN, hoe interpreteert ArcGIS dit dan? Waarschijnlijk in de grillen van degene die de shapefile-lezer codeerde (wat betekent dat het ArcGIS-gedrag op elk moment kan veranderen, afhankelijk van de versie, de release en de bugfix die momenteel van kracht is :-).
toegevoegd de auteur whuber, de bron