Mehr

Hinzufügen von Knoten zu einem Polygon mit FME

Hinzufügen von Knoten zu einem Polygon mit FME


Ich habe eine Vektordatei mit einem einzelnen, einfachen Polygon (vielleicht 10 Knoten). Ich möchte diesem Polygon weitere Knoten hinzufügen und die ursprüngliche Form beibehalten.

Die offensichtliche Frage ist hier 'warum willst du das tun?'. Es löst ein weiter nachgelagertes Problem im Prozess. Es ist ein Hack.

Ist das bei FME möglich? Können Sie eine Vektordatei einlesen, ihr Knoten hinzufügen und sie wieder ausschreiben? Mit welchem ​​Transformator könnten Sie das erreichen?


Wie in den Kommentaren erwähnt, ist der Transformator, den Sie suchen, der Verdichter.

Aus der Hilfe:

Fügt jedem Feature Stützpunkte hinzu, indem neue Koordinaten in festen Intervallen interpoliert werden.

Sie haben die Möglichkeit, die Scheitelpunkte in gleichmäßigen Abständen oder in einem definierten Intervall zu erstellen.

Wie mKurowsKi betont, gibt es in FME natürlich viele Möglichkeiten, dies zu tun.


Wie immer bei FME gibt es viele Möglichkeiten, diese Aufgabe zu erfüllen.

Hier ist eine Möglichkeit, die sich um Iterative Snipper dreht (erhältlich im FME Store):


Ein Algorithmus zum Einpassen eines Rechtecks ​​in ein Polygon

ich habe eine Art Schnittproblem. Es gibt ein unregelmäßiges Polygon ohne Löcher und eine Liste von rechteckigen Kacheln in Standardgröße und ihren Werten.

Ich möchte, dass ein effizienter Algorithmus die einzelne Kachel mit dem besten Wert findet, die in dieses Polygon passt, oder einen Algorithmus, der nur sagt, ob eine einzelne Kachel in das Polygon passt. Und es sollte in deterministischer Zeit für unregelmäßige Polygone mit weniger als 100 Scheitelpunkten laufen.

Bitte beachten Sie, dass Sie das Polygon und die Kacheln drehen können. Antworten/Hinweise für konvexe und nicht-konvexe Polygone sind willkommen.


Reiter "Geographie"

Auf der Registerkarte "Geografie" wird der Begrenzungsrahmen der Daten auf einer Karte angezeigt. Es zeigt das Datenformat, die Anzahl der Elemente, den Geometrietyp, das Koordinatensystem, die Bounding-Box-Koordinaten, den Datenmaßstab und die Auflösung an.

Abb. 62 : Einzelausgabe - Registerkarte Geographie

DefinitionFläche der Ressource im geografischen Raum, ausgedrückt als Grenzpolygon
IndikationenDer Begrenzungsrahmen muss alle im Dataset enthaltenen Objekte umfassen. Bei der manuellen Bearbeitung muss das Grenzpolygon genau angepasst werden, um die Grenze für die entsprechende Ressource möglichst genau darzustellen (definieren Sie kein Rechteck, das ein ganzes Land abdeckt für Daten, die auf eine Stadt beschränkt sind). Idealerweise deckt das Grenzpolygon nur zusammenhängende Räume ab und muss für nicht zusammenhängende Gebiete multipliziert werden.
Wenn mehrere Begrenzungsboxen vorhanden sind, dürfen sie sich nicht überlappen.
Abb. 63: Zeigt die konvexe Hülle für ein gegebenes Datenelement auf einer Karte an
INSPIRE-AnforderungVerpflichtend
StapelausgabeJa, durch Überschreiben
ScanJa, konvexe Hülle
SuchmaschineNein

Tipp: Wenn der Scan den konvexen Umschlag nicht automatisch erkennt, schlagen Sie im entsprechenden Anhang nach.

So zeichnen Sie den Begrenzungsrahmen der Daten manuell auf der Karte:

  1. Klicken Sie auf "Bearbeiten".
  2. Wählen Sie auf der Karte das Werkzeug "Polygon zeichnen" oder "Rechteck zeichnen".
  3. Zeichnen Sie den Begrenzungsrahmen auf der Karte.
  4. Doppelklicken Sie zum Abschluss auf die Karte oder klicken Sie erneut auf den ersten Gipfel des Polygons.
  5. Speichern.

Anzahl der Entitäten

DefinitionAnzahl geografischer Objekte
IndikationenMuss eine ganze Zahl sein.
Beispiel20
INSPIRE-AnforderungOptional
StapelausgabeJa, durch Überschreiben
ScanJawohl
SuchmaschineNein

Geometrie

DefinitionGeometrietyp für geografische Objekte
IndikationenEiner der folgenden Werte:
- Punkt,
- Linienfolge,
- Polygon,
- Mehrpunkt,
- MultiLineString,
- MultiPolygon,
- GeometrieSammlung,
- Kreisförmige Zeichenfolge,
- Verbundkurve,
- Kurvenpolygon,
- MultiKurve,
- MultiSurface,
- Kurve,
- Oberfläche,
- PolyederOberfläche,
- ZINN
BeispielPolygon
INSPIRE-AnforderungVerpflichtend
StapelausgabeJa, durch Überschreiben
ScanJawohl
SuchmaschineNein

Koordinatensystem

DefinitionName und EPSG-Code für das geografische oder projizierte Koordinatensystem
IndikationenWenn das System nicht automatisch erkannt wurde, wählen Sie einen Wert aus der Liste aus, der Administrator kann diese Liste anpassen (siehe das entsprechende Kapitel).
BeispielEPSG-Code: 2154
Name: RGF93 / Lambert-93
INSPIRE-AnforderungVerpflichtend
StapelausgabeJa, durch Überschreiben
ScanJawohl
SuchmaschineFilter

Tipp: Wenn der Scan das Koordinatensystem nicht automatisch erkennt, lesen Sie den entsprechenden Anhang.


GIS-Konvertierungsprojekt von Vision zu Esri

Ein wichtiger Bestandteil des langfristigen Re-Engineering-Plans des Orange County Property Appraisers (OCPAs) war die Umwandlung seiner Grundstücksbewertungsbasis von Vision zu ArcInfo. Dies wurde in einem Joint Venture zwischen OCPA und Safe Software unter Verwendung der Feature Manipulation Engine (FME) durchgeführt. Die Aufgabe wurde gelöst, indem die Vision GIS-Strukturen seitlich verschoben und die zugrunde liegenden relationalen Tabellenstrukturen direkt mit dem FME getroffen wurden, um die über 4 Millionen geometrischen Objekte sauber in ArcInfo zu konvertieren. Zu den Herausforderungen bei der Konvertierung dieses Datensatzes gehörten die schiere Datenmenge, der Umgang mit einem Datensatz, der nicht einfach räumlich aufgeteilt werden konnte, sowie die Bereinigung und Übertragung der kritischen paketbezogenen Informationen des Landkreises. Darüber hinaus wendete das Immobilienbewertungsbüro strenge Qualitätskontroll- und Sicherungsverfahren an, um sicherzustellen, dass alle Informationen korrekt übertragen wurden und um Datenprobleme auf der Vision-Seite zur Korrektur vor der endgültigen Konvertierung zu identifizieren. In diesem Papier werden der Lebenszyklus des Umbaus und die vielen Herausforderungen und Erfolge auf diesem Weg erörtert.

Abbildung 1. Orange County, Florida

1.3 Technische und Prozessübersicht *

2.0 Übersetzung von Vision zu E00 *

3.0 Qualitätssicherung und Fehlerbeseitigungΐ

Das Büro des Liegenschaftsgutachters (OCPA) von Orange County beschloss, sein geografisches Informationssystem (GIS) von Vision auf das Datenmodell und die Softwareprodukte von Esri umzustellen, hauptsächlich aus zwei Gründen:

Das OCPA-Personal benötigte geeignete Werkzeuge, um schnell Softwareanwendungen zu entwickeln, um auf das im GIS gespeicherte Wissen zuzugreifen. Inzwischen bot der Arbeitsmarkt nur wenige Kandidaten mit Vision-Programmiererfahrung. Darüber hinaus hatte Vision kein "out-of-the-box" benutzerfreundliches Softwarepaket für den Desktop-PC, ein Punkt, der vom Immobiliengutachter als kritisch eingestuft wurde. Das Büro des Immobiliengutachters stellte fest, dass ein einfach zu bedienendes Desktop-Paket für die schnelle Entwicklung und Verbreitung anspruchsvoller Tools zur räumlichen Analyse an Nicht-Programmierer in der Organisation unerlässlich war, die nur minimale Schulungen erforderten. Vor der Konvertierung waren die OCPA GIS-Benutzer auf eine angepasste Vision-Anwendung beschränkt, die am Vorabend erstellte Steuer-Rasterkarten anzeigte. Der Zugriff auf "live" GIS-Daten war nicht verfügbar. Änderungen an Vision-Kartenvorlagen erforderten einen langwierigen Programmieraufwand und die Vision-Software stellte begrenzte topologische Regeln bereit, was zu Problemen mit der Datenintegrität führte (z. B. enthielt die Datenbank offene Flurstückpolygone, doppelte Bögen und Straßenmittellinien, die sich manchmal nicht kreuzten).

OCPA benötigte ein Softwarepaket von einem Marktführer, das ein fortschrittliches Datenmodell zur Verwendung mit einem kommerziellen relationalen Datenbankmanagementsystem (RDBMS) bot und über eine vollständige Palette von GIS-Produkten verfügte, die das Spektrum von "Power", "Moderate" und "Casual" GIS bedienen konnten Benutzer in der Organisation. Dieser Punkt war besonders wichtig, da OCPA sich darauf vorbereitete, seine gesamte GIS-Paketdatenbank zu überarbeiten. Die 1998 existierende Datenbank wurde Ende der 1980er Jahre durch Scannen, Digitalisieren und Gummierungen entwickelt. Begrenzte Vermessungsdaten waren mit Bodenkontrolle verfügbar. Der Plan für 1999 war zweierlei: Abstimmung mit Orange County und Städten in der Grafschaft, um das rechteckige Vermessungsnetz der Grafschaft auf ein halbes Meile-Raster zu verdichten, und Koordinatengeometrieverfahren (COGO) zu verwenden, um Grundstücksgrenzen unter Verwendung der Originalquelle in das GIS einzugeben Dokumente (dh Plats und Urkunden). Esri bot die beste Softwarelösung, um diese Ziele zu erreichen.

Um die Informationen aus Vision in die Esri GIS-Lösung zu übersetzen, benötigte OCPA ein Softwaretool mit den folgenden Eigenschaften:

Die ausgewählte Anwendung war die von Safe Software Inc. entwickelte Feature Manipulation Engine (FME Ò ). Die FME ist in der Lage, direkt aus der Oracle-Quelldatenbank zu lesen, die die Vision-Datenbank enthielt, die extrahierten Features zu einer konsistenten Geometrie und Topologie zusammenzusetzen und zu schreiben dies direkt in alle von Esri unterstützten Formate. Damit erhielt OCPA eine Anwendung, die nicht nur die Übersetzung der Quelldaten unterstützte, sondern auch eine leistungsstarke Toolbox zum Identifizieren und Beheben von Problemen in der Quelldatenbank bereitstellte. Ein Übersetzungsprozess könnte definiert und die Konvertierung automatisiert werden. Darüber hinaus bietet das FME derzeit ein vielseitiges Datenübersetzungsportal, das Informationen aus der neuen GIS-Datenbank in einer Reihe von branchenüblichen GIS-Formaten wie AutoCAD DWG/DXF, MicroStation DGN und MapInfo an die Außenwelt übermittelt, um nur einige zu nennen.

Der Plan zur Neugestaltung der Paketdatenbank erforderte einen vierstufigen Prozess:

Vor Beginn der Konvertierung analysierten die Mitarbeiter von OCPA das vorhandene Vision-Datenschema. Seit Ende der 1980er Jahre wurden nur wenige Unterlagen gesammelt. Außerdem mussten die Vision-Layer und "Netzwerke" in das gewünschte ArcInfo-Coverage- und Feature-Class-Schema abgebildet werden. Dieser Prozess wurde als erster Schritt durchgeführt und umfasste sowohl individuelle Forschung als auch gemeinsame Teamsitzungen.

Der Prozess der Übersetzung der Informationen aus der Vision-Datenbank in E00-Dateien und schließlich in die SDE-Produkte umfasste drei Datenspeicher und drei automatisierte und einen manuellen Prozess. Dies ist in Abbildung 2 dargestellt.

Die Vision-Datenbank und das GIS-System liefen in einer Solaris-Umgebung, wobei die Übersetzungen von FME sowohl auf Solaris als auch auf NT durchgeführt wurden. Die Verarbeitungsumgebung von Vision GIS bestand aus Anwendungssoftware, proprietären Daten, die wie Symbologie- und Annotationsplatzierungsinformationen gespeichert sind, und einer Anwendungsdatenbank in Oracle. Die nach dem Vision-Schema erstellte Oracle-Datenbank enthielt die Geometrie, Topologie und Links zu Geschäftsdaten für den Landkreis. Vision verwendet eine netzwerkbasierte Topologie, bei der Daten nach Schichten und Netzwerken unterschieden und gruppiert werden. Dies wird in Abschnitt 2.0 ausführlicher besprochen

Nach der Evaluierung verschiedener Hardwareoptionen entschied sich OCPA für die Implementierung einer dreistufigen Lösung. Diese bestand aus einem Unternehmens-UNIX-Server, der SDE 3.0.2 unterstützte und auf Oracle 8.0.4 lief, um die räumlichen und Eigenschaftsattributinformationen zentral zu speichern. Ein NT-Server fungierte als ArcInfo-Lizenzmanager für Arbeitsgruppen, während NT-Workstation-Clients ArcInfo 7.2 für die Datenpflege nutzten. Zur Datenanzeige und -analyse wurde ArcView 3.2 verwendet. Die Datenkonvertierung wurde mit FME sowohl auf dem NT- als auch auf dem UNIX-Server durchgeführt. Dieser zweigleisige Ansatz ermöglichte es dem Amt, mehrere CPUs und Datenträgerressourcen zu nutzen. Dies war angesichts der Größe der Datenbank wichtig.

Die Vision-Datenbank wurde mit FME für Esri, Version 2.3a, sowohl in Solaris- als auch in NT-Umgebungen übersetzt.

Es gab zwei Möglichkeiten, diese Daten aus Vision mit der FME über GINA-Dateien (das Vision-Exportformat) wiederherzustellen oder direkt auf das Oracle-Schema zuzugreifen und die Topologie direkt aus der Geometrie zu rekonstruieren. Letzteres wurde in erster Linie gewählt, weil ein Ansatz erforderlich war, der Vision in Zukunft überflüssig machen würde (das Schema kann auch nach Ablauf der Vision-Software aufgerufen werden) und um die Produktivität der Qualitätssicherung zu erhöhen (robustere und interaktivere Tools, sofern in Esri . verfügbar) Produktpalette).

Eine vereinfachte Version des Schemas für eine Vision-Datenbank ist in Abbildung 3 dargestellt. Die Tabelle g_master enthält für jedes Feature in der Datenbank eine Zeile, die durch eine Kombination aus Feature-Nummer, Typ, Layer und Netzwerk eindeutig identifiziert wird. Diese Tabelle identifiziert ein einzelnes Feature innerhalb der Vision-Datenbank. Sammlungen von Features des gemeinsamen Themas werden nach ihrer Layer- und Netzwerknummer aus der g_master-Tabelle gruppiert. Diese Abfrage kann nach Geometrietyp untergruppiert werden. Die unterstützten Typen sind Punkt, Linie, Polygon und Knoten. Die von den Tabellen g_master (Master oder Primär) zurückgegebenen Zeilen werden nach Feature-Nummer mit der Tabelle g_coord (Koordinaten) verknüpft. Je nach geometrischem Typ erfolgt die Verknüpfung mit der Tabelle g_coord entweder eins zu eins (Punkte oder Knoten) oder eins zu vielen (Linien und Polygone). Der Join vom g_master zur Business-Tabelle ist immer eins zu eins, und der Join zum g_label (Annotation oder Labeling) ist eins zu vielen.

Das Vision Oracle-Schema verwendet eine zentrale Feature-Tabelle, die nach Layern und Netzwerken klassifiziert ist. Einfache und komplexe Geometrien werden abgerufen, indem alle Koordinaten für ein gegebenes Feature (identifiziert durch eine eindeutige ganze Zahl) für eine gegebene Layer-Netzwerk-Kombination unter Verwendung einer SQL-Select-Anweisung für eine Koordinatentabelle ausgewählt werden. Unter Berücksichtigung des Geometrietyps (Punkt, Linie, Polygon oder Annotation) wurden die richtigen FME-Features konstruiert. Je nach Art der zu konstruierenden Geometrie wurden verschiedene topologische Konstruktionen von der FME durchgeführt. An den Punktdaten war keine Konstruktion erforderlich. Für lineare Features wurde die Erkennung von Kreuzungen erkannt und eingefügt. Bei Polygon- und Donut-Features wurden Schnittpunkte erkannt und eingefügt, und ungültige Polygone wurden getrennt von den gültigen Polygonen identifiziert und gespeichert. Schließlich wurden alle Punkt-, Linien- oder Polygon-Annotationen rekonstruiert und in eine Text-Unterklasse platziert. In einigen Fällen wurden die Annotationsplatzierungswerkzeuge der FME verwendet, wenn die detaillierten Platzierungsinformationen nicht aus Vision wiederhergestellt werden konnten (einige Fälle gab es, in denen die Annotationsplatzierung von Vision in Nicht-Schema-Tabellen gespeichert wurde, auf die nicht zugegriffen werden konnte). Außerdem wurden Geschäftsattribute für das gegebene Feature mit der Geometrie verbunden.

Abbildung 3: Vision-Datenmodell

Abbildung 4. Liste mit separaten SDE-Tabellen für jede Haupt-Feature-Class

Die Übersetzungsübung für FME wurde zu einer Abfrage-, Interpretations-, Validierungs- und Schreibschleife. Die Iteration in der Schleife wurde für jede Kombination aus Layer, Netzwerk und Feature-Typ durchgeführt. Alle Daten würden von Oracle mithilfe einer Multi-Join-SQL-Abfrage ausgewählt. Die zurückgegebenen Daten wurden in ihren geometrischen Typ umgewandelt und in das richtige Koordinatensystem umgewandelt (eine Verschiebung und Skalierung war erforderlich, um das Vision-Koordinatensystem mit der Zustandsebene auszurichten). Wenn der geometrische Typ eine lineare Komponente hatte, wurden Gruppen- und Selbstschnitttests an den Linien durchgeführt. Wenn der Geometrietyp polygonal war (einschließlich Donuts), wurden Tests durchgeführt, um offene Polygone, Polygone ohne Beschriftungen und Polygone mit mehreren Beschriftungen zu erkennen. Für die konvertierten Layer legt das Polygon entweder gebildete Partitionen oder Partitionen mit Löchern fest (in allen Fällen wurden überlappende Bereiche erkannt und aufgelöst).

Die FME steuert alle Übersetzungen entweder mit systemgenerierten oder benutzerdefinierten Zuordnungsdateien. Mapping-Dateien sind ASCII-Textdateien, die von der FME zur Laufzeit interpretiert werden. Abhängig von dem individuell zu entwickelnden Prozess kann eine gute Architektur bei der Entwicklung und bei der Lösung von Datenproblemen sehr hilfreich sein.

Die Zuordnungsdateien enthalten fünf Hauptkomponenten:

Architektonisch können sowohl der Reader als auch der Writer und ihre Definitionen durch andere Quell- und Zielformate ersetzt werden. Die eigentliche Arbeit wird in Schritt 3 erledigt, der im Wesentlichen formatneutral ist. Abbildung 5 zeigt den Informationsfluss durch die FME bei der Umwandlung von Vision- in E00-Funktionen.

Abbildung 5: Datenfluss durch FME

Für die OCPA-Implementierung wurde die Reader-Definition für jede Tabelle aus einer Vorlage gebildet, die eine SQL-Abfrage auf die Extraktion von Merkmalen aus der Datenbank anwendete. Diese Vorlage wurde an jede Abfrage für Features angepasst und bot eine saubere und generische Methode zur Modellierung der Quelldaten.

Die Menge an fehlerhaften Daten, die in linearen und polygonalen Features in Vision gefunden wurden, lag in der Größenordnung von 0,01 Prozent. Bezogen auf das Datenvolumen des Sets (mehr als 2 Millionen) sind das jedoch über 20.000 Features. Die meisten dieser Fehler konnten leicht lokalisiert und behoben werden. Aufgrund von Inkonsistenzen in der netzwerkbasierten Topologie der Quelldaten war jedoch eine Linienkreuzung in Verbindung mit einer Polygonbildung erforderlich.

Der größte polygonale Datensatz sind die Lot-Layer, die aus über 1.000.000 Bögen und 200.000 Zentroiden bestehen. Die Verarbeitung, die die FME vor dem Schreiben in E00 durchführte, um die topologische Integrität sicherzustellen, war:

Die erste und dritte Operation sind global, da alle Informationen über die Geometrie erforderlich sind, um eine Linie-zu-Linie-Schnitt- und Polygonkonstruktion korrekt durchzuführen. Sie können keines der Probleme teilen und überwinden. Wenn der gesamte Datensatz geladen und verarbeitet wurde, war der Speicherverbrauch sowohl des realen als auch des virtuellen Speichers hoch, und das Ergebnis war ein an Festplatten-E/A gebundener Prozess. Um die Verarbeitung zu beschleunigen, mussten die Daten partitioniert werden. Die Vision-Datenbank war nahtlos und bot daher keine direkte Partition. Es gab jedoch Geschäftsattribute, die die Grundlage für eine Partition bildeten. Folgende Schritte wurden durchgeführt:

Dieser Ansatz ermöglichte die Wiederherstellung aller Polygone aus der Vision-Datenbank. Außerdem ermöglicht dieser Ansatz den Einsatz mehrerer Prozessoren, um das Polygonbildungsproblem parallel zu lösen. Ein Nebeneffekt dieses Ansatzes war, dass Grundstücke, die falsch dem falschen Township/Bereich zugeordnet wurden, leicht identifiziert werden konnten. Zusammenfassend lässt sich sagen, dass dieses Leistungsproblem gelöst wurde, indem das County in eine Sammlung von Puzzleteilen zerlegt wurde, die zum größeren County wieder zusammengesetzt wurden.

Die OCPA-Qualitätskontrolle bestand aus einer Reihe topologischer Regeln und Überprüfungsverfahren, die die ordnungsgemäße Datenintegrität für die Verwendung mit den Esri-Produkten sicherstellen sollten. Die Mitarbeiter beschlossen, die Vision-Daten zunächst in ArcInfo-Exportdateien zu konvertieren, bevor die Features schließlich in SDE/Oracle gespeichert wurden. Die Daten wurden in Coverages umgewandelt, damit die Diagnosefunktionen von ArcInfo während der Qualitätssicherung genutzt werden konnten. Nach dem Import wurden ArcInfo-Coverages mit häufig verwendeten Themen erstellt (z. B. Flurstücke, Grundstücke, Unterteilungen usw.). OCPA hielt sich an umfassende Qualitätssicherungsverfahren mit ArcInfo (ArcEdit, ArcPlot und INFO) und ArcView-Software, um die langfristige Funktionsfähigkeit der räumlichen und Attributdaten in einer Esri-Umgebung sicherzustellen. ArcView wurde verwendet, um die konvertierten Daten qualitativ zu überprüfen (z. B. Suche nach der richtigen Position von Flurstücken und korrekten Flurstücksattributen), während ArcInfo verwendet wurde, um die topologische Integrität zu überprüfen (z. B. Schließen die Polygone? Überschneiden sich die Bögen? Sind die internen IDs konsistent und stable?, etc.), ein kritischer Test für die spätere Verwendung. Die Qualitätssicherungsverfahren waren wie folgt:

  1. Untersuchen Sie die räumlichen Daten und Attribute visuell auf korrekte Position, fehlende Polygone, Bögen, Punkte, Anno, Kartenmaßstab usw. in ArcView und ArcEdit
  2. Geben Sie nach dem Importieren der e00-Datei einen ArcInfo-Befehl "describe" für eine Übersicht aus und stellen Sie sicher, dass die Anzahl der Beschriftungspunkte (Schwerpunkte) für ein Poly-Coverage um 1 kleiner ist als die Anzahl der Polygone

- Hinweis: Polygonflächenwerte sollten sich nach einem "build" nicht ändern

  • der $RECNO-Wert = cover# für das PAT
  • the LAB cover# = the PAT cover# für denselben Datensatz
  • die PAT-Cover-ID kann einen Wert von 1 weniger als die Cover-Nr haben
  • die LAB-Cover# ist 1 mehr als die LAB $RECNO
  • Jedes Polygon außer dem Universe-Poly hat einen Labelpoint (Schwerpunkt)
  • eine Bearbeitung des Coverages wie Zusammenführen, Teilen, Löschen oder Hinzufügen, gefolgt von einem Erstellen und Speichern, funktioniert fehlerfrei
  • die benutzerdefinierten Attribute des Label-Punkts (LAB) = die Poly-Attribute für denselben Datensatz (d. h. dieselbe Cover-ID)
  • Geben Sie ein: ef poly sel box, dann list $recno, cover#, cover-id
  1. Überprüfen Sie in INFO (oder Arc: list cover.pat) die PAT-Datei, um sicherzustellen, dass:
  • das Universum ist die Datensatznummer ($RECNO) = 1
  • die Covernummer des Universums ist auch 1
  • die Universums-Cover-ID = 0
  • die Fläche des Universums ist ein negativer Wert
  • der Umfang des Universums ist ein positiver Wert
  • das Universum hat keine benutzerdefinierten Attribute
  1. Führen Sie einen Clean & Build für die Abdeckung durch, um sicherzustellen, dass:
  • die benutzerdefinierten Attribute bleiben erhalten und sind in der richtigen Reihenfolge
  • die zugehörige Annotation behält die richtige Reihenfolge bei
  • ArcInfo meldet korrekte Topologie
  • Siehe #3 oben
  • Wenn das Polygon-Coverage keine Labelpoints hat, erstellen Sie Labelpoints in Arc, führen Sie dann einen Build durch und überprüfen Sie das Coverage auf korrekte Topologie
  1. Vergleichen Sie die feat_num für ein bestimmtes ArcInfo-Poly mit derselben Feat_num in VISION (ist die mit diesem Poly verknüpfte Feature-Nummer in der VISION-Datenbank dieselbe wie in der FME-Ausgabe?)
  2. Folgendes sollte nach einem Import für alle Polygone Labels erstellen und die Topologie korrigieren:
  • Bogen: build cover_bd
  • Bogen: createlabels cover_bd 0
  • Bogen: build cover_bd

Nachdem diese Regeln erfüllt waren, wurden die Daten mithilfe von SDE-Verwaltungsskripten in SDE geladen. Die Parzellen- und Parzellendeckungen für die verdichteten Stadtgebiete mussten vor Beginn der Verladung zunächst zu gemeindenahen Deckungen zusammengefasst werden.

Es ist wichtig anzumerken, dass im Laufe des Sommers und Frühherbstes 1999 eine Reihe von iterativen Testkonvertierungen durchgeführt wurden, um die Konvertierungssoftware abzustimmen, die Bearbeitungszeiten zu erfassen, unsere Qualitätssicherungsverfahren zu verfeinern und die Vision-Daten auf Fehler. Dieser Ansatz deckte eine Reihe von Problemen mit den Vision-Daten auf. Die Datenmängel reichten von doppelten Bögen, getrennten Straßenmittellinien und unterbrochenen Hydrografiebögen bis hin zu offenen Flurstückpolygonen und falsch codierten Flurstücken und Unterteilungen. Auf diese Weise konnten wir viele der Daten bereinigen, bevor wir Coverages in SDE laden.

Die konvertierten ArcInfo-Coverages wurden nach Abschluss aller QA in SDE geladen. Während des Ladens der Daten und der anschließenden Abstimmung und Verwendung der Daten wurden mehrere wertvolle Beobachtungen/Lektionen gewonnen. SDE bot vor allem schnellen Zugriff auf eine lückenlose landesweite Datenbank mit über 300.000 Paketdatensätzen und 27 SDE-Tabellen. Räumliche Daten und Attribute konnten innerhalb von Sekunden überall im Landkreis abgerufen werden. Um diese Leistung zu optimieren, war es erforderlich, die Datenbank zu optimieren und die Daten-Layer in separate Feature-Class-Tabellen aufzuteilen. Die Mitarbeiter von OCPA entwickelten auch benutzerdefinierte AMLs, um die Daten für die Paketwartung zu importieren und zu exportieren. FME wurde erweitert, um Mapping zu unterstützen, das die Daten aus SDE in verschiedene Formate exportiert: E00, Shape, DXF, DGN und MIF (für Datenanfragen und GIS-Partnerdatenaktualisierungen). ArcInfo verfügte über Befehle zum Exportieren von Daten aus SDE als Form und Abdeckung, sogar als DXF-Dateien. Die Umstellung auf DGN und MIF stellte jedoch eine größere Herausforderung dar. FME bietet ein leistungsstarkes Werkzeug, um all diese Aufgaben mit einem einzigen Softwareprodukt zu erledigen.

Unter den gewonnenen Erkenntnissen haben wir Folgendes festgestellt:

Abbildung 6. Beispiel einer OCPA-Internet-Mapping-Anwendung, die Daten verwendet, die mit FME-Software konvertiert wurden


Alle Geometrien können eine beliebige Anzahl von Merkmalen aufweisen. Dies sind Attribute auf Geometrieebene und nicht auf Feature-Ebene. Hierarchische Geometrien können an jedem Knoten in der Geometriehierarchie separate Merkmale aufweisen.

Dieses im FME Data Inspector dargestellte Aggregat-Feature weist beispielsweise fünf Merkmale auf, die mit seiner Geometrie verknüpft sind. Diese Eigenschaften wurden von einem Trimble SketchUp-Reader geerbt.


MAPublisher 10.1 veröffentlicht

Wir freuen uns, Ihnen mitteilen zu können, dass wir MAPublisher 10.1 für Adobe Illustrator veröffentlicht haben. Das Produktteam von MAPublisher hat eng mit unseren Kunden zusammengearbeitet, um diese Funktionen zu entwickeln, um die Produktivität beim Kartendesign zu verbessern.

MAPublisher 10.1

Dieses Update enthält neue Funktionen und Leistungsverbesserungen sowie Fehlerbehebungen für gemeldete Fehler. Einige Highlights werden unten erwähnt, die vollständigen Versionshinweise finden Sie unten.

Aktualisieren Sie vorhandene Legenden automatisch, wenn MAP-Designs geändert werden. Es ist hier! Legenden von MAP-Designs können jetzt automatisch aktualisiert werden, wenn Legendenelemente in einem Design aktualisiert werden. Dies ist eine große Zeitersparnis, wenn Sie sich in der Feinabstimmungsphase der Auswahl der richtigen Farbpalette für Ihre Karte befinden und Ihre Legende nicht manuell aktualisieren müssen.

Neue Möglichkeit zum Erstellen von Linien aus Text auf einem Pfad. Erstellt eine Linie basierend auf einem Text in einer Pfadquelle. Es ist nützlich zum Erstellen von Karten-Features und zur Unterstützung bei der Indexierung für manuell erstellte Karten (d. h. Szenarien, in denen Text manuell erstellt wurde, anstatt aus Attributwerten erstellt zu werden). Das Textdienstprogramm kann auf Text auf einer bestimmten Ebene, auf eine bestimmte MAP-Ansicht, auf das gesamte Dokument oder nur auf ausgewählten Text angewendet werden.

Neue Möglichkeit, Seitenzahlen beim Erstellen von Indizes einzubeziehen. Im Werkzeug „Index erstellen“ bietet eine neue Option „Seitenzahlen einbeziehen“ die Möglichkeit, eine einzelne Zeichenfläche (horizontal oder vertikal) in der Mitte zu teilen, um Indizes zu erstellen, die einen Verweis auf eine Seite enthalten (links oder rechts, oben oder unten). Diese Funktion ist nützlich, wenn sich eine Karte über eine einzelne Zeichenfläche erstreckt, die in einer endgültigen Ausgabe auf zwei Seiten aufgeteilt werden soll (z. B. eine Doppelseite in einem Atlas). Text und Features, die sich über beide “Seiten” erstrecken, können im Index so aufgelistet werden, dass sie auf beiden Seiten erscheinen (d. h. die Ausdehnung des Textes oder Features indiziert).

Export in das GPS Exchange-Format (GPX) wird jetzt unterstützt. MAPublisher unterstützt seit langem den GPX-Import und unterstützt jetzt den GPX-Export. Es ist ein Format, das Tracks, Routen und Punkte enthält und zum Austausch von Daten zwischen GPS-Geräten und Kartensoftware verwendet wird. Es ist mit der Avenza Maps-App und vielen anderen Anwendungen von Drittanbietern kompatibel.

Neue Möglichkeit, Diagramme nach Radius zu skalieren. Sie haben jetzt die Möglichkeit, MAP-Diagramm-Themen-Kreisdiagramme nach Radius zu skalieren, zusätzlich zur bestehenden Methode der Flächennutzung. Dies bietet eine weitere Feinabstimmungsebene beim Anpassen von Diagrammen, um eine korrekte proportionale Skalierung zu erhalten. Denken Sie daran, dass im Dialogfeld Skalierung erweiterte Skalierungsfunktionen verfügbar sind (klicken Sie einfach auf die Schaltfläche Skalierung). Weitere Informationen zur Diagrammskalierung finden Sie hier.

MAPublisher 10.1 Versionshinweise

  • Aktualisieren Sie vorhandene Legenden automatisch, wenn MAP-Designs geändert werden
  • Neue Möglichkeit zum Erstellen von Linien aus Text auf einem Pfad
  • Neue Möglichkeit, Seitenzahlen beim Erstellen von Indizes einzuschließen
  • Export in das GPS Exchange-Format (GPX) jetzt unterstützt
  • Neue Möglichkeit, Diagramme nach Radius zu skalieren
  • Eine Reihe von Verbesserungen der Benutzeroberfläche und Benutzerfreundlichkeit.

Migrieren des “Unusual” in ArcGIS/ArcFM

Am Ende des Films wendet sich Casablanca Captain Renault bekanntlich von Rick ab und befiehlt seinem Sergeant, "die üblichen Verdächtigen zusammenzutreiben". (Ich liebe diesen Film – und ich liebe diese Zeile wirklich.) Wenn wir über die Migration von Daten in ein Dienstprogramm oder eine ArcGIS/ArcFM-Geodatabase des Telekommunikationsunternehmens sprechen, dann sind die „üblichen Verdächtigen“ AutoCAD, Microstation, Smallworld und Intergraph. Diese Produkte machen den Großteil aus, von dem Kunden Daten in Arc migrieren. Bei diesen Technologien verlassen wir uns in der Regel für einige Aspekte des Migrationsprozesses auf die FME von Safe Software – entweder für die Extraktion in eine „Staging“-Datenbank oder für die Unterstützung der gesamten Migrationspipeline.

Es gibt jedoch immer noch Produkte und selbst entwickelte GIS- und Kartierungslösungen, die außerhalb der üblichen Verdächtigen liegen. Für diese gibt es keine FME-Reader (wir befinden uns im obigen Diagramm im Bereich des „Prozesstyps 3“.) In einigen Fällen gibt es nicht einmal eine Dokumentation. Daher kann es sein, dass ein gewisses Maß an „GIS-Archäologie“ erforderlich ist, um Datenstrukturen und Beziehungen aufzudecken, die für die Zuordnung eines Quellsystems zu einem ArcGIS/ArcFM-Zieldatenmodell unerlässlich sind.

Im Laufe der Jahre hatten wir die Gelegenheit, mit einer Reihe (*) der „ungewöhnlichen Verdächtigen“ zusammenzuarbeiten und freuen uns sehr, dass wir erfolgreich Migrationen von diesen Quellen in ArcGIS/ArcFM-Geodatabases abgeschlossen haben. Wir können auch sagen, dass diese Systeme zwar nicht die beliebtesten sind, aber nicht unbedingt schlecht konzipiert oder implementiert sind. Viele Faktoren tragen zum Erfolg auf dem GIS-Markt bei, und technische Exzellenz ist nur einer davon – dennoch hatten wir einige „was haben sie sich dabei gedacht“-Momente.

Glücklicherweise gibt es zwischen solchen Systemen immer eine gewisse Gemeinsamkeit, die das Mapping und die Datenmigration überhaupt erst ermöglicht. Zu den wichtigen gemeinsamen Eigenschaften zählen:

• Alle verfügen über einen Mechanismus zum Unterscheiden von Gerätetypen und zum Zuordnen bestimmter Attributsätze zu diesen Typen.
• Alle haben eine Möglichkeit, Geometrien für räumliche Features zu beschreiben, obwohl die Techniken sehr unterschiedlich sind.
• Die meisten haben einen Mechanismus, um zu beschreiben, was mit was verbunden ist – aber auch hier variiert die Laufleistung.

Hier sind jedoch einige Merkmale / Kategorisierungen, die wir auf unsere „ungewöhnlichen Verdächtigen“ anwenden können:

• Asset-Systeme, die ein X, Y mit Tags versehen. Wenn es unter diesen ungewöhnlichen Systemen irgendeinen Grad an Gemeinsamkeit gibt, dann ist der, dass die „Mapping“-Komponente so etwas wie ein nachträglicher Gedanke an ein anderes, primäres Ziel des Systems ist. Fast so, als ob jemand, der mitten in der Entwicklung ein Asset-Management-System aufbaut, eine „Mapping“-Anforderung auf ihn hat, also fügt er X, Y-Felder zu einer Tabelle hinzu und nennt es gut.

In diesem Fall kann das Kernprodukt selbst keine Funktionen in einer Kartenanzeige rendern, sondern bietet die Möglichkeit, Daten in Form einer AutoCAD-Zeichnung oder DXF-Datei aus dem System zu extrahieren und die Zeichnung anschließend für Aktualisierungen zu durchsuchen, die müssen auf die Asset-Datenbank angewendet werden. In diesem Fall kann es verlockend sein, die AutoCAD-Zeichnung(en) als Quelle für die Migration zu verwenden – dies wäre jedoch falsch und würde zu einem unvollständigen Migrationsprozess führen. Der DWG/DWF ist im Wesentlichen ein „Bericht“, der eine Teilansicht der Daten darstellt. Eine vollständige Migration muss zu der wahren Datenquelle gehen.

Ein verwandtes Merkmal ist, dass Koordinaten in einem einzigen, vermuteten Koordinatensystem gespeichert werden. Es gibt keine "räumliche Referenz"-Eigenschaft, wie wir sie in einer ArcGIS-Geometriedefinition finden würden, die das Projizieren der Geometrie ermöglicht. Also… müssen wir die vermutete Projektion (normalerweise eine Zustandsebene oder ein UTM-Gitter) aus einer anderen Quelle lernen.

• Hinzufügen von „Form“-Punkten. Natürlich erkennen selbst Systeme mit begrenzten Zielen für das „Mapping“, dass das Hinzufügen von X, Y allein die grundlegenden Mapping-Anforderungen nicht erfüllt. Einige Geräte sind linear. Und es kann sogar gelegentlich erforderlich sein, ein Polygon darzustellen. Wir haben interessante Möglichkeiten gesehen, dies zu erreichen, von denen die einfachste darin besteht, eine Tabelle mit „Form“-Punkten hinzuzufügen, wie hier dargestellt. Aus Sicht der Migration ist das Vorhandensein einer „Form“-Tabelle ein willkommener Anblick. Dies bedeutet, dass wir die ursprüngliche Kartografie wahrscheinlich mit hoher Genauigkeit reproduzieren können.

In anderen Fällen muss die Form eines linearen Features möglicherweise basierend darauf abgeleitet werden, womit das Gerät verbunden ist oder wovon es unterstützt wird. In dem unten abgebildeten Beispiel müssten wir erhalten die Lage eines elektrischen Leiters anhand der Lage seiner „von“- und „zu“-Pole (oder von und zu Bauwerken, einschließlich unterirdischer Ausrüstung). Scheint auf einer Ebene einfach zu sein, aber die Komplexität wird erhöht, wenn mehrere Leiter auf einer Pollinie vorhanden sind, insbesondere wenn unser Ziel ein geometrisches ArcGIS-Netzwerk ist, das auf geografischer Koinzidenz beruht, um die Konnektivität herzustellen. Bei einer speziellen Verarbeitung, die eine Versatzlogik beinhaltet, würden wir am Ende mit zusammenfallenden Merkmalen enden, die zu einer Reihe unerwünschter „Schleifen“ führen. Während nach Abschluss des automatisierten Prozesses einige manuelle Bereinigungen erforderlich waren, zeigt das Diagramm unten einen Teil einer Strategie, die wir angewendet haben, um diesem Zustand Rechnung zu tragen.

• Konnektivitätstabelle. It may be that in addition to the comparatively simple task of plotting X, Y coordinates the system seeks to maintain a representation of network connectivity, though the connectivity may be relatively coarse and may not correspond to how we would expect connectivity to be presented in an ArcGIS geometric network. An example for an electric distribution network is a simple device hierarchy table that contains each device and its parent. Such “device-parent” tables have been critical components of historical asset management systems and can help a company quickly answer questions such as “what customers are served under what device.” However another aspect of device-parent tables is that they are quite difficult to maintain and thus prone to error. Good thing GIS technology has matured to the point of being able to table over this responsibility!

The table may, or may not distinguish between a “parent” device which is simply a device immediately upstream of the current device from a “protective parent” device which is the next upstream device that has the ability to open when excessive current from a downstream fault is induced. Knowing the parent protective device could be important for supporting applications such as outage management. Adding the protective parent column would result in a table as that at the right.

The connectivity table may be much more complex and may include associations among alle network equipment, even to the point of describing associations between current-carrying equipment and the structures that support that equipment and attachments to support structures. An illustration is to the right. In this case the “topology” table includes definitions of not only what is connected to what, but also the manner in which they are connected. Mining a topology table such as this in a data migration context can provide the ability to help ensure that ArcGIS network connectivity is correct but also can help building relationships – such as the “Structure Relate” relationship often present in ArcFM utility Geodatabases.

A further variation on this theme is the case where a network is comprised of links, and nodes and points – with links connected to one another at nodes and that have points also potentially connected to nodes. In some cases there may be more than one point feature connected to a node. So envision the case of a gas distribution network where three pipes meet at a node and that two point features, a tee and a reducer are also connected to the node.

Whatever manner of connectivity may be defined explicitly in the source database it can only help so much in establishing comparable connectivity in the target ArcGIS geometric network, with the key reason being that the geometric network relies on geographic coincidence and in systems with connectivity tables the feature geographic location is (or at least can be) completely independent of network connectivity.

So, what does this all mean for our data migration task? Well, a variety of things depending on the exact content of the source database. But it might mean that we can only use the connectivity table as a means to validate results and not as a tool that can be used directly in the migration process. Consider the following example.

In this case we may have discovered feature geometries from a “shape” table and have device connectivity in a separate “parent device” table, but the two are not related. The best we might be able to do is determine cases where a device parent in our target ArcGIS/ArcFM Geodatabase differs from the device parent as defined in the source database.

A convenient way to do this is to take advantage of the ArcFM Objects method IMMElectricTracingEx.TraceDownstream. This returns a set of junction network elements downstream of a starting point, typically a feeder circuit breaker. Importantly, the method also returns the parent junction for each network junction traced, allowing us to walk upstream from any device and identify its parent – or with a little extract logic determine its protective parent.

Below is a depiction of what our trace results might show from the example above. Specifically we would see that transformer XFM1 has a different parent and FUS2 has no parent. In this simple example the cause is quite clearly the fact that FUS2 is offset from the primary line and not included in the network (of course we could have also seen this issue by inspecting our geometric network build errors.) However, a point to keep in mind through this process is that the discrepancy we see between source and target network representations could be due to an error in the source network.

• Internal Connectivity. In some specialized cases a source system may have particular rules and data structures for associating equipment in enclosures such as fiber optic cable patch locations or electrical distribution system switch cabinets. In such cases there may only be a geometry definition for the enclosure location itself and the remaining geometries and relationships must be generated from an associated internal connectivity table. Below is an example illustrating a migration strategy we employed in a similar case.

• Attribution. Feature attributes may be stored in discrete tables per equipment type – similar to the ArcGIS model – or there may be a single table containing attributes for all features organized as key-value pairs as illustrated to the left below. A variation on this approach is that there may be a look-up table defining attribute types associated with a feature that is required to join a particular feature definition to its attributes. In either case a compelling aspect of this organization is that no data model changes are required to add or alter attributes associated with an equipment type. Though that’s academic. Either source model can be accommodated in the data migration process.

Abschluss
We’ve offered a brief survey of some common characteristics of GIS/mapping system that we’ve found to fall outside the mainstream of current use and some of the migration strategies we’ve employed to successfully move this data into ArcGIS/ArcFM Geodatabases. Though there is some effort in constructing and configuring the logic for specialized processing, the fact that the whole (or vast majority) of the process can be automated and is repeatable can provide significant benefits given that migrations of this type typically need multiple iterations to perfect.


MAPublisher 10.2 Released

We’re excited to announce the release of MAPublisher 10.2 for Adobe Illustrator. The MAPublisher product team has been working closely with our customers to build these features to improve map design productivity.

MAPublisher 10.2

This update contains new features and performance improvements as well as fixes for reported issues. Some highlights are mentioned below, for the full release notes see below.

Filter layers and attributes with expressions on import. This feature that has been requested by many users in the past and we’re happy to say it’s finally here! While filtering attributes and geometry has been available since MAPublisher 10.0, the ability to filter specific layers and attributes using an expression was not available until now. This let’s you fine-tune your layer and attribute filter to only include (or exclude) specific data at the attribute value level. This improves Adobe Illustrator performance by reducing the number of map features and attributes being imported. The Filter Geometry feature has been renamed Spatial Filter and it retains the same functionality. In addition, these filtering and simplification tools reside together in an improved user interface.

Simplify complex art on import. Another new import feature that reduces the amount of data is Simplification. It allows for the simplification or generalization of vector line and area data during data import instead of after. Using simplification during import reduces the number of map features and attributes being imported and improves overall performance. Simplification can be applied to all art together or applied separately to lines or areas and use either the Douglas-Peucker or Visvalingam-Whyatt method for removing nodes and vertices.

New support for WFS 2.0, AutoCAD 2018, and OGR formats. Several new formats are supported and updated in MAPublisher 10.2. The WFS 2.0 specification improves on a number of functionalities including r esponse paging. More than 1,000 features can be loaded from a WFS server now. The AutoCAD 2018 format allows you to import and export version 22.0 DXF, DWG and DGN files. Read and write capabilities have been improved by updating OGR import formats (GML and PostGIS) and OGR export formats (GML and GeoJSON).

Overprint option for MAP Legend art. Overprint is essential in print production and reduces unsightly edges that could appear if printing plates are not perfectly aligned. MAPublisher generated art from Scale Bar, Grids and Graticules, and MAP Theme legends now have an overprint setting to ensure that art can be maintained as MAPublisher objects without having to expand art as separate objects, strokes, and fills.


Avenza Releases MAPublisher 10.2 For Adobe Illustrator

Improved layer, attribute, and feature filtering and simplification capabilities

Toronto, ON, July 10, 2018 – Avenza Systems Inc., producers of the Avenza Maps® app for mobile devices and geospatial plug-ins for Adobe Creative Cloud, including Geographic Imager® for Adobe Photoshop®, is pleased to announce the release of MAPublisher® 10.2 for Adobe Illustrator.

This MAPublisher release improves on streamlining data import, specifically the ability to target specific layers, attributes, and features using filtering options and tools. In addition, requested features such as new format support and GeoJSON export are also included in this release.

“Over the past several quarters, we have reached out to numerous cartographers and GIS professionals to gain insight on map production workflows and best practices,” said Ted Florence, President of Avenza. “We’re learning a lot and excited to continuously work with the mapping community to support their efforts and projects to map this world using the MAPublisher tools they love.”

Enhancements and new features of MAPublisher 10.2

  • Filter layers and attributes with expressions on import
  • Simplify complex art on import
  • Import support for WFS 2.0 and AutoCAD 2018
  • Export support for GeoJSON and AutoCAD 2018
  • User interface and usability enhancements

More about MAPublisher for Adobe Illustrator

MAPublisher for Adobe Illustrator is powerful map production software for creating high-quality maps from GIS data. MAPublisher cartographic tools leverage the superior graphic design environment of Adobe Illustrator to manipulate features and produce print-ready, mobile, and online maps with accuracy and efficiency.


MAPublisher 10 Released

We’re excited to announce that we’ve released MAPublisher 10 for Adobe Illustrator. The MAPublisher product team has been working closely with our customers to build more useful features, tools, and to improve the look and feel.

MAPublisher 10

This update contains new features and performance improvements as well as fixes for reported bugs. Some highlights are mentioned below, for the full release notes see below.

Adobe Illustrator Creative Cloud 2018 support. We are fully committed to providing the best map design tools seamlessly built into Adobe Illustrator. We have improved our user interface (panels, tools, buttons) to support high-resolution monitors. This release is fully compatible with the latest Adobe Illustrator CC 2018 on both Windows (32-bit and 64-bit) and Mac.

Manage Data Links. This feature has long been requested by our customers. You now have the ability to create and manage data links for MAPublisher documents. MAP layers in a document can be updated when its source data has been modified. Data links are checked automatically every time a document is opened and will display the status of affected layers in the MAP Views panel. This allows you to keep track of data that may have been moved or modified. When a data source is missing, a notification will alert you in both the Edit Data Link dialog box and MAP View panel. Note that only the link is dynamic and not the actual map features, meaning that manipulating your features in the document does not directly affect the source data. You will need to export your data if you want to overwrite your source data.

Filter attributes and filter geometry on import. A common workflow our customers encounter is trying to reduce the amount of data being imported. Often times, a dataset covers a much larger area or has too many attributes included. There is now a way to streamline import so that it’s not only quicker to import, but also results in improved Adobe Illustrator performance due to the reduction in the number of map features on the artboard. The new attribute filter helps you select which layer attributes (or layers) to include or not include prior to import. The new geometry filter provides several options (including an interactive map) to help you select which area to include or not include prior to import.

Redesigned Scale Bar tool. We’ve worked a lot with our customers to redesign the scale bar tool. In addition to new customization options, new scale bar styles were generated with the help of the US National Park Service, Harpers Ferry Center. You also now have the ability to save, import, and export scale bar styles, making it easier to share defined styles with others.

Improved MAP Tagger Tool. You now have the ability to create custom leader lines with various arrow styles and option to snap leader line to different positions around a label. This provides a new level of customization and efficiency without having to style leader lines afterwards.

New Simplify Art simplification method. A new Visvalingam-Whyatt simplification method and fault tolerance setting to accommodate positional error between shared edges in the topology. The Visvalingam-Whyatt method is an area based algorithm which eliminates points based on their effective area. By iterating through points of lines and areas, it calculates and removes the point with the least effective area.


Schau das Video: How to Carry Out a Point in Polygon Operation in FME