MapPoint Web Service Find APIs - Understanding Entities and Entity Relationships
(Page 3 of 4 )
Entities in MapPoint Web Service represent real things (e.g., countries, cities, landmarks, schools) that exist in the real world. All entities are first-class citizens in the world of MapPoint Web Service; they have type definitions, carry their own identities, enjoy entity-level find capabilities, maintain relationships, and in some cases even persist their identity across different versions of MapPoint Web Service.
Before I get into too many details, here is an example to help you understand this concept. Consider the United States: in MapPoint Web Service, the country is an entity with entity ID 244; the states contained within it are represented as children entities to the United States entity. Counties, cities, and towns within these states are represented as the children entities to the state entities; this parent-child relationship continues down to things like bridges, roads, parks, and schools. Figure 6-1 summarizes this discussion by showing the entity relationships for the town of Redmond, WA.
How do all the entities and entity relationships defined in MapPoint Web Service help you? The short answer is that you can issue smarter and more focused find queries to find things that suit your needs. Many applications require you to drill down into the subgeographic areas starting with a larger coverage. To continue with our United States example, you may want to develop an application where your customers start with the United States, go to the 50 states in the United States, pick a state
Figure 6-1. Entity parent-child relationships
and get all counties, pick a county and get all cities, and pick a city and get all interested entities within it. Entities are used to issue queries with limited geographic context (such as all states within the United States). You can also add your own custom entity types (or points of interest) that allow you to find places using the entities and entity relationships.
Programmatically, all entities are represented by theEntityclass, and the definition of an entity type is represented by theEntityType class. TheEntityTypeobjects define the schema of an entity type, including the name, parent, and valid properties of an entity type.
Each physical entity represented using theEntityclass has anID, aDisplayName, which is a long descriptive name, and a common shortName. AnEntityobject also indicates the type of entity using theTypeNamefield (which is astring); this type name maps to a correspondingEntityTypeobject. Finally, anEntityobject exposes a collection of properties specific to that entity type as an array ofEntityPropertyValueobjects. TheEntityPropertyValueobject is a simple name value pair that gives you the name and value of the property. If you know an entity’s properties, you can issue queries to find entities by their properties—we will look at this concept later in this chapter.
If you find the concepts ofEntityTypeandEntityconfusing, think of it this way: anEntityTypedefines the schema, and anEntityrepresents the instance of a “thing” with that schema (similar to the difference between a class and an object). For example, the entity typePopulatedPlacedefines the schema and parent-child relationships for geographic entities such as cities, towns, and villages; the entity typePopulatedPlaceis represented by theEntityType class programmatically. The city of Paris is an entity of typePopulatedPlace, so the actual city is represented by anEntityobject programmatically with aTypeNameofPopulatedPlace.
Next: Data Sources and Entity Types >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter six of the book Programming MapPoint in .NET, written by Chandu Thota (O'Reilly; ISBN: 0596009062). Check it out today at your favorite bookstore. Buy this book now.
|
|
