Samengevoegde gegevens samenvoegen in ArcSDE master geodatabase?

Ik heb wat suggesties/inspiratie nodig voor een probleem dat we hebben.

Het probleem:

We hebben een ArcSDE-master GIS-database. We zullen deze gegevens bijna uitsluitend buiten ArcGIS en buiten ArcSDE bewerken. Met andere woorden, we zullen een klein gedeelte exporteren en dit bewerken. Vervolgens zullen we deze gegevens terugsturen naar een andere SDE-tabel (diff-database). We zullen ook een extra attribuut handhaven dat bevat: toevoegen, verwijderen, bewerken.

Wat we nu willen doen, is deze diff-tabel naar de master te schrijven. Mijn vraag is wat de beste tool is om dit te doen? Gebruik maken van Arcpy met cursor, met FME, of zijn er andere ArcGis-tools om te helpen? Ik zat te denken met ArcPy en deed zoiets als dit:

  • voeg eenvoudig alle objecten toe met status-add.
  • zoek naar elke id met status delete en verwijder deze
  • zoek naar alle ID's met statusbewerking en kopieer de bewerkte bestanden

Wat is volgens jou de beste tool om dit te doen?

  • Arcpy?
  • FME
  • directe SQL (we gebruiken MS SQL)
  • anderen ...

De hoofddatabase bevindt zich in het bereik van ongeveer 500.000 objecten, dus de uitvoering is misschien een probleem. Op dit moment denken we aan een synchronisatiebewerking waarbij een operator de synchronisatie start en kan wachten tot deze is voltooid, zodat hij een aantal controles kan uitvoeren nadat deze is voltooid.

Bonusvragen: We moeten ook dimensioneringen en labels synchroniseren. Het probleem is dat we deze in de diff-database waarschijnlijk niet als arcgis-dimensionerende feature classes kunnen opslaan, maar het zijn line-en-point-symbolen met de nodige data erop. Kunnen we dezelfde techniek gebruiken voor het transformeren en migreren van deze gegevens zodat deze in de dimensioneringsklassen past?

5
Met de opname van uw "Bonusvragen" denk ik dat deze vraag breder wordt dan de "één vraag per vraag" die een schone Q & A helpt. Ik raad aan dat je je vraag bewerkt om ze te verwijderen en, als ze nog steeds belangrijk zijn, om ze te onderzoeken/apart te vragen.
toegevoegd de auteur UnkwnTech, de bron
Net zoals u weet, kunt u tabellen niet via SQL wijzigen als u versiebeheer gebruikt. ArcGIS kan de wijzigingen niet "zien".
toegevoegd de auteur commonpike, de bron

3 antwoord

Een aanpak die ik met succes heb gebruikt en die redelijk goed lijkt te presteren in FME, is om drie kolommen te maken in de hoofdklasse "master" op SDE:

  1. Een veld met de oorspronkelijke OID van de functie (of een andere unieke ID).
  2. (Optioneel) Een veld met de oorspronkelijke naam van de featureklasseklasse (gebruikt als u meerdere bronfunctieklassen hebt die naar de masterklassieklasse gaan)
  3. Een kolom met een CRC ( Cyclic Redundancy Check ) -waarde voor elke functie. Deze waarde wordt gegenereerd met de transformator CRCCalculator . Zie ook dit FMEpedia-artikel waarin wordt uitgelegd hoe dit kan worden geïmplementeerd.

Vervolgens lees ik in zowel de bronkenmerkklasse als de hoofdkenmerkklasse en "join" (met een FeatureFusie ) bij een aaneenschakeling van de oorspronkelijke naam van de ID en de bronfunctieklasse.

Nu afhankelijk van welke poort de functie de FeatureMerger verlaat, weet je of het een add-on, delete of als de feature in beide plaatsen bestaat.

U hoeft dan alleen maar de CRC opnieuw te berekenen op de binnenkomende functie en deze te vergelijken met de opgeslagen CRC. Als de CRC anders is, is het een update. Als het hetzelfde is, is de functie niet veranderd.

U weet dan of elke functie moet worden bijgewerkt, verwijderd, toegevoegd of overgeslagen. Zorg ervoor dat u de juiste streams routeert (invoer versus master) en verwissel de waarden geodb_oid niet, want u wilt de OID's van de master gebruiken voor verwijderingen en updates. Voor toevoegingen doet het er niet toe. Let op de AttributeRenamer-stap in het FMEpedia-voorbeeld; ze gebruikten dit om te voorkomen dat FeatureFraude bestaande attributen overschreef.

Het FMEpedia-voorbeeld verzendt elk databasetransformatietype (bijwerken/verwijderen/toevoegen) naar afzonderlijke schrijvers, maar u kunt een handige truc gebruiken om slechts één schrijver te gebruiken door het kenmerk fme_db_operation in te stellen op UPDATE, INSERT of DELETE en het instellen van de schrijver-modus op UPDATE. Deze techniek wordt beschreven in dit FMEpedia-artikel .

U kunt natuurlijk ook tijdstempelkolommen toevoegen om te registreren wanneer een functie voor het eerst werd geladen en als laatste werd gewijzigd met de TimeStamper transformator.

Merk op dat deze benadering je waarschijnlijk in staat zou stellen om de "diff" -tabelstap geheel over te slaan, en ik geloof dat FME ook klassen van dimensie- en annotatiefuncties prima ondersteunt, dus hopelijk werkt de aanpak hetzelfde of heeft hij slechts kleine aanpassingen nodig (nooit gebruikt) ze zelf).

5
toegevoegd
Dank je voor het antwoord. Ik gebruik FeatureFusion niet, omdat ik de "ADD/EDIT/DELETE" -velden kan gebruiken. Ik heb de fme_db_operation gebruikt. de techniek beschreven in het artikel is perfect. Nu moet ik nog controleren hoe ik de klassen voor dimensionering en annotatie zal doen, maar de eerste stap is al aan de gang.
toegevoegd de auteur user2722, de bron

Als u Registreren als versie met de optie om bewerkingen naar basis te verplaatsen en uw gegevens op te slaan met SQL Server Spatial type in plaats van SDE Binary, kunt u uw gegevens rechtstreeks bewerken met behulp van SQL Server en ArcGIS zal de wijzigingen zien.

Vervolgens kunt u overwegen om met behulp van SQL Server-replicatie (zoals samenvoegreplicatie) technieken een kopie van de gegevens op een externe locatie uit te pakken voor offline bewerking.

1
toegevoegd

Mijn onmiddellijke gedachte zou zijn om opgeslagen procedures in MS SQL te gebruiken om dit te bereiken. Ik heb geen statistieken, maar ik zou aannemen dat het verreweg de snelste manier is omdat het 'native' zou zijn. Wat u vraagt ​​is vrij eenvoudig. Gewoon een lus door de diff-tabel die sql-statements afgeeft aan de master db.

Ik weet echter niet genoeg over het dimensioneren van FC, dus ik kan je hier niet mee helpen! Ik neem aan dat je in dit geval ArcPy zou moeten gebruiken omdat het weet hoe de objecten in de geodatabase moeten worden opgeslagen. Tenzij je natuurlijk weet (reverse engineer) welke tabellen worden bijgewerkt wanneer een dimensioneringsklasse wordt gemaakt.

0
toegevoegd
Nee, er zijn veel verschillende tabellen die een feature class vormen. Hier is een visueel overzicht: help.arcgis.com/en /arcgisdesktop/10.0/help/002p/pdf/…
toegevoegd de auteur blah238, de bron
Is de toewijzing tussen ArcSDE en MS SQL 1 op 1, met andere woorden, alle informatie van een object opgeslagen in een tabel in MS SQL of moet ik naar een aantal verschillende tabellen schrijven?
toegevoegd de auteur user2722, de bron
@ blah238 Bedankt voor het overzicht. mapoholic, voorlopig gebruik ik fme omdat het goed genoeg lijkt te werken. Als dit echter niet lukt, zou ik kunnen overwegen MS SQL direct te gebruiken.
toegevoegd de auteur user2722, de bron
Dat is misschien zo, maar het zijn allemaal metadata ALS je geen bewerkingen uitvoert met ESRI-tools EN ALS de gegevens zijn opgeslagen in MS SQL-indeling, lijkt dit het geval te zijn. Als u bijvoorbeeld een ruimtelijke tabel in MS-SQL hebt en u voegt een geometrieleeks toe met behulp van de opdrachtregel SQL, dan wordt de nieuwe record weergegeven in ArcMap. Ik heb dit geprobeerd met behulp van Oracle-gegevens en het werkt prima
toegevoegd de auteur posipiet, de bron