WO2011095226A1

WO2011095226A1 - Apparatus and method for generating a view

Info

Publication number: WO2011095226A1
Application number: PCT/EP2010/051493
Authority: WO
Inventors: Witold Studzinski
Original assignee: Tomtom Polska Sp.Z.O.O
Priority date: 2010-02-08
Filing date: 2010-02-08
Publication date: 2011-08-11

Abstract

A navigation and/or mapping apparatus comprises: a processing resource (202) operably coupled to a data store (214, 293), wherein the data store (214, 293) is adapted to store at least one footprint source and the processing resource (202) is adapted to obtain a footprint (294) from the footprint source, generate a model (320) of a structure based on the footprint (294) and provide image data relating to the model (320).

Description

APPARATUS AND METHOD FOR GENERATING A VIEW

Field of the Invention

The present invention relates to a mapping system or navigation apparatus of the type that, for example, provides a three-dimensional model or view in respect of a location.

Background to the Invention

Portable computing devices, for example Portable Navigation Devices (PNDs) that include GPS (Global Positioning System) signal reception and processing functionality are well known and are widely employed as in-car or other vehicle navigation systems.

In general terms, a modern PND comprises a processor, memory (at least one of volatile and non-volatile, and commonly both), and map data stored within said memory. The processor and memory cooperate to provide an execution environment in which a software operating system may be established , and additionally it is commonplace for one or more additional software programs to be provided to enable the functionality of the PN D to be controlled, and to provide various other functions.

Typically these devices further comprise one or more input interfaces that allow a user to interact with and control the device, and one or more output interfaces by means of which information may be relayed to the user. Illustrative examples of output interfaces include a visual d isplay and a speaker for audible output. Illustrative examples of input interfaces include one or more physical buttons to control on/off operation or other features of the device (which buttons need not necessarily be on the device itself but could be on a steering wheel if the device is built into a vehicle), and a microphone for detecting user speech. In one particular arrangement, the output interface display may be configured as a touch sensitive display (by means of a touch sensitive overlay or otherwise) additionally to provide an input interface by means of which a user can operate the device by touch.

Devices of this type will also often include one or more physical connector interfaces by means of which power and optionally data signals can be transmitted to a n d re ce i ve d fro m t h e d ev i ce , a n d o pt i o n a l l y o n e o r m o re wi re l es s transmitters/receivers to allow communication over cellular telecommunications and other signal and data networks, for example Bluetooth, Wi-Fi, Wi-Max, GSM, UMTS and the like.

PNDs of this type also include a GPS antenna by means of which satellite- broadcast signals, including location data, can be received and subsequently processed to determine a current location of the device.

The PND may also include electronic gyroscopes and accelerometers which produce signals that can be processed to determine the current angular and linear acceleration, and in turn, and in conjunction with location information derived from the GPS signal, velocity and relative displacement of the device and thus the vehicle in which it is mounted. Typically, such features are most commonly provided in in- vehicle navigation systems, but may also be provided in PNDs if it is expedient to do so.

The utility of such PNDs is manifested primarily in their ability to determine a route between a first location (typically a start or current location) and a second location (typically a destination). These locations can be input by a user of the device, by any of a wide variety of different methods, for example by postcode, street name and house number, previously stored "well known" destinations (such as famous locations, municipal locations (such as sports grounds or swimming baths) or other points of interest), and favourite or recently visited destinations.

Typically, the PND is enabled by software for computing a "best" or "optimum" route between the start and destination address locations from the map data. A "best" or "optimum" route is determined on the basis of predetermined criteria and need not necessarily be the fastest or shortest route. The selection of the route along which to guide the driver can be very sophisticated, and the selected route may take into account existing, predicted and dynamically and/or wirelessly received traffic and road information, historical information about road speeds, and the driver's own preferences for the factors determining road choice (for example the driver may specify that the route should not include motorways or toll roads).

In addition, the device may continually monitor road and traffic conditions, and offer to or choose to change the route over which the remainder of the journey is to be made due to changed conditions. Real time traffic monitoring systems, based on various technologies (e.g. mobile phone data exchanges, fixed cameras, GPS fleet tracking) are being used to identify traffic delays and to feed the information into notification systems.

PNDs of this type may typically be mounted on the dashboard or windscreen of a vehicle, but may also be formed as part of an on-board computer of the vehicle radio or indeed as part of the control system of the vehicle itself. The navigation device may also be part of a hand-held system, such as a PDA (Portable Digital Assistant), a media player, a mobile phone or the like, and in these cases, the normal functionality of the hand-held system is extended by means of the installation of software on the device to perform both route calculation and navigation along a calculated route.

Mapping, route planning and navigation functionality may also be provided by a desktop or mobile computing resource running appropriate software. For example, the Royal Automobile Club (RAC) provides an on-line route planning and navigation facility at http://www.rac.co.uk, which facility allows a user to enter a start point and a destination whereupon the server with which the user's computing resource is communicating calculates a route (aspects of which may be user specified), generates a map, and generates a set of exhaustive navigation instructions for guiding the user from the selected start point to the selected destination. The facility also provides for pseudo rendering of a calculated route, and route preview functionality which simulates a user travelling along the route and thereby provides the user with a preview of the calculated route.

In the context of a PND, once a route has been calculated, the user interacts with the navigation device to select the desired calculated route, optionally from a list of proposed routes. Optionally, the user may intervene in, or guide the route selection process, for example by specifying that certain routes, roads, locations or criteria are to be avoided or are mandatory for a particular journey. The route calculation aspect of the PND forms one primary function, and navigation along such a route is another primary function.

During navigation along a calculated route, it is usual for such PNDs to provide visual and/or audible instructions to guide the user along a chosen route to the end of that route, i.e. the desired destination. It is also usual for PNDs to display map information on-screen during the navigation, such information regularly being updated on-screen so that the map information displayed is representative of the current location of the device, and thus of the user or user's vehicle if the device is being used for in-vehicle navigation.

An icon displayed on-screen typically denotes the current device location, and is centred with the map information of current and surrounding roads in the vicinity of the current device location and other map features also being displayed. Additionally, navigation information may be displayed, optionally in a status bar above, below or to one side of the displayed map information , examples of navigation information include a distance to the next deviation from the current road required to be taken by the user, the nature of that deviation possibly being represented by a further icon suggestive of the particular type of deviation, for example a left or right turn. The navigation function also determines the content, duration and timing of audible instructions by means of which the user can be guided along the route. As can be appreciated a simple instruction such as "turn left in 100 m" requires significant processing and analysis. As previously mentioned, user interaction with the device may be by a touch screen, or additionally or alternately by steering column mounted remote control, by voice activation or by any other suitable method.

A further important function provided by the device is automatic route recalculation in the event that: a user deviates from the previously calculated route during navigation (either by accident or intentionally); real-time traffic conditions dictate that an alternative route would be more expedient and the device is suitably enabled to recognize such conditions automatically, or if a user actively causes the device to perform route re-calculation for any reason.

It is also known to allow a route to be calculated with user defined criteria; for example, the user may prefer a scenic route to be calculated by the device, or may wish to avoid any roads on which traffic congestion is likely, expected or currently prevailing. The device software would then calculate various routes and weigh more favourably those that include along their route the highest number of points of interest (known as POIs) tagged as being for example of scenic beauty, or, using stored information indicative of prevailing traffic conditions on particular roads, order the calculated routes in terms of a level of likely congestion or delay on account thereof. Other PO I-based and traffic information-based route calculation and navigation criteria are also possible.

Although the route calculation and navigation functions are fundamental to the overall utility of PN Ds, it is possible to use the device purely for information display, or "free-driving", in which only map information relevant to the current device location is displayed, and in which no route has been calculated and no navigation is currently being performed by the device. Such a mode of operation is often applicable when the user already knows the route along which it is desired to travel and does not require navigation assistance.

Furthermore, the device may be used to display map information relating to a location input by the user, wherein the location may have no relation to the user's current location.

Devices of the type d escri bed above , for exam ple the 920T model manufactured and supplied by TomTom International B.V., provide a reliable means for enabling users to navigate from one position to another. Such devices are of great utility when the user is not familiar with the route to the destination to which they are navigating.

As detailed above, the memory of the PND stores map data used by the PND not only to calculate routes and provide necessary navigation instructions to users, but also to provide visual information to users through the visual display of the PND.

Map information can be expressed in a number of ways and indeed can com prise a nu mber of separate information components, which are used in combination by the PND. For example, information can be expressed as various birds-eye map projections, satellite images, terrain information, field of view images and 3D models. 3D models and field of view images may advantageously give an impression of the view that a user might see if they were at a location, which may help, for example, in recognising the location.

3D models may be defined using 3 dimensional coordinates of vertices that make up the model. Optionally, some data for texture mapping may also be stored. The result of this is that a considerable amount of data is required in order to generate 3D models.

For PND's or other mapping systems that provide three-dimensional imaging of a route or location, the 3D image or model can take up a large amount of memory or disk space. This is particularly problematic for portable devices or devices in which the memory or other storage space is limited. Furthermore, transmission of model data, for example over a network or communications link, may take up considerable bandwidth and/or may require a long time to transmit.

Summary of the Invention

Various aspects of the present invention are defined in the independent claims. Some preferred features are defined in the dependent claims.

According to a first aspect of the present invention , there is provided a navigation and/or mapping apparatus comprising: a processing resource operably coupled to a data store, wherein the data store is adapted to store at least one footprint source and the processing resource is adapted to obtain a footprint from the footprint source, generate a model of a structure based on the footprint and provide image data relating to the model.

The apparatus may comprise a display device operably coupled to the processing resource, the processing resource supporting, when in use, a view generation engine and the display device being arranged to receive the image data from the view generation engine and display an image responsive to the image data.

The footprint and/or the model may be an image.

The footprint may be a building footprint. The footprint may define a 2 dimensional representation of the building. The footprint may define a perimeter, outline or border of a building. The perimeter may comprise a series of component lines, which may define at least one polygon.

The footprint source may comprise a footprint. The footprint source may comprise a birds-eye view, aerial view, satellite view and/or plan view image. The processing source may be adapted to determine at least one footprint from the footprint source, which may comprise edge detection, pattern matching or the like.

The model may be a 3 dimensional (3D) model. Although references are made herein to 3D models, it will be appreciated that such models may be virtual 3D models, represented on a flat screen display but whose display comprises a representation of depth and/or may be rotatable to be viewed from any angle.

The 3D model may be a 3D model representing at least part of a building. The processing resource may be adapted to convert 2D footprint images into

3D model images.

The processing resource may be adapted to generate walls for the model by extrapolating the footprint through a distance corresponding to a wall height.

The processing resource may be adapted to determine a roof shape using the footprint. The roof shape may comprise a 3D roof model.

The processing resource may be adapted to determine vertices of the footprint. The vertices may comprise a point at which the perimeter changes direction. The vertices may represent a corner of a building.

The processing resource may be adapted to determine bisectors for at least one, and preferably each, vertex of the footprint. The bisectors may comprise a straight line passing through a vertex, and extending internally of the footprint and having an equal angle between the bisector and each portion of the footprint forming the vertex.

The processing resource may be adapted to determine intersections between bisectors. The processing resource may be adapted to determine only the closest intersection to the associated vertex for at least one, and preferably each, bisector.

The processing resource may be adapted to disregard any second and subsequent intersection on at least one, and preferably each, bisector.

The processin g resou rce may be adapted to determine the closest intersection or intersections to the perimeter and may be adapted to calculate a shift amount corresponding to the d istance between the closest i ntersection or intersections and the perimeter of the footprint.

The processing resource may be adapted to generate lines forming roof features, the generated lines lying parallel to corresponding constituent lines of the footprint, and shifted toward the centre of the footprint by an amount corresponding to the shift distance from a corresponding constituent line of the footprint such that each point on each generated line lies a distance corresponding to the shift distance from the closest point on the footprint. It will be appreciated that, depending on the geometry of the footprint, the roof features may comprise one or more polygons, lines or points.

I n cases where the roof features comprise at least one polygon, the processing resource may be adapted to repeat the above process using the polygon as a starting point rather than the footprint, i.e. the processing resource may be adapted to determine vertices of the polygon, determine bisectors associated with at least one vertex of the polygon, determine intersections between the bisectors, determine a shift distance corresponding to a d istance between the closest intersection to the polygon and generate further roof features by generating further lines lying parallel to corresponding constituent lines of the polygon, and shifted toward the centre of the polygon by an amount corresponding to the shift distance from a corresponding constituent line of the polygon such that each point on each further generated line lies a distance corresponding to the shift distance from the closest point on the polygon.

The processing resource may be adapted to iteratively repeat the roof feature generation process until no further polygons are generated, and all polygons have been degenerated to lines or points.

The processing resource may be adapted to remove at least one and optionally all polygons and/or bisectors, which may be removed dependent on roof type.

The data store may comprise metadata related to the footprint.

The processing resource may be adapted to determine metadata related to the footprint. The processing resource may be adapted to determine metadata related to the footprint based on a shape and/or scale of the footprint, which may comprise using typical metadata associated with a shape and/or scale of the footprint. The processing resource may be arranged to determine footprint meta data associated with buildings in a neighbourhood or predetermined distance of the building whose model is to be determined and determining metadata associated with the footprint based on the metadata of the neighbouring buildings.

The meta data may comprise wall height and/or a roof height and/or texture information and/or a roof type. The processing resource may be adapted to generate a 3D model using the footprint and metadata related to the footprint.

The roof height meta data may comprise a total roof height. The processing resource may be adapted to associate lines and/or points forming the roof features and portions of the original footprint with heights, based on the total roof height and the iteration of the roof features determination process in which the line or point was generated.

The processing resource may be adapted to generate a roof model using the generated roof feature and corresponding heights.

The processing resource may be adapted to generate walls of the model by extrapolating a footprint upwards by a distance corresponding to the wall height meta data.

The processing resource may be adapted to generate a building model by combining the roof model with the walls of the model.

The navigation and/or mapping apparatus may comprise a location determination unit operably coupled to the processing resource and adapted to determine a location.

The navigation and/or mapping apparatus may comprise a user input device. The navigation and/or mapping apparatus may be adapted to receive an input location, which may be input via the user input device.

The processing resource may be adapted to retrieve or determine at least one footprint associated with a location as determined by the location determining unit and/or the input location.

The processing resource may be adapted to generate a field of view around a determined or input location using the footprint data associated with the location. The field of view may comprise one or more 3D models.

According to a second aspect of the invention is a navigation and/or mapping system comprising: a navigation and/or mapping apparatus as set forth above in relation to the first aspect of the invention; wherein the data store is remotely located from the navigation and/or mapping apparatus and accessible via a communications network.

According to a third aspect of the invention is a navigation and/or mapping system comprising: a navigation and/or mapping apparatus as set forth above in relation to the first aspect of the invention and/or a navigation and/or mapping system as set forth above in relation to the second aspect of the invention ; wherein the display is remotely located from the navigation and/or mapping apparatus and/or system and is in communication with the processing resource via a communications network.

According to a fourth aspect of the present invention, there is provided a method for generating an image, the method comprising: obtaining at least one building footprint; determining a roof height; and generating a 3D roof model using the footprint and the roof height.

The method may comprise generating and displaying a 3D model of the building, the building model comprising the roof model.

The method may comprise determining vertices of the footprint.

The method may comprise determining bisectors for at least one, and preferably each, vertex of the footprint.

The method may comprise determining intersections between bisectors. The method may comprise determining only the closest intersection to the associated vertex for at least one, and preferably each, bisector and/or to disregard the second and subsequent intersection on at least one, and preferably each, bisector.

The method may comprise determining the closest intersection or intersections to the outline or border. The method may comprise determining the distance between the closest intersection or intersections and the outline or border of the footprint.

The method may comprise determining the closest intersection or intersections to the perimeter and calculating a shift amount corresponding to the distance between the closest intersection or intersections and the perimeter of the footprint.

The method may comprise generating lines forming roof features, th e generated lines lying parallel to corresponding constituent lines of the footprint, and shifted toward the centre of the footprint by an amount corresponding to the shift distance from a corresponding constituent line of the footprint such that each point on each generated line lies a distance corresponding to the shift distance from the closest point on the footprint. It will be appreciated that, depending on the geometry of the footprint, the roof features may comprise one or more polygons, lines or points.

In cases where the roof features define at least one polygon, the method may comprise repeating the above roof feature generation process using the polygon as a starting point rather than the footprint, i.e. determining vertices of the polygon , determine bisectors associated with at least one vertex of the polygon, determining intersections between the bisectors, determining a shift distance corresponding to a distance between the closest intersection to the polygon and generating further roof features by generating further lines lying parallel to corresponding constituent lines of the polygon , an d sh ifted towa rd the centre of th e polygon by an am ou nt corresponding to the shift distance from a corresponding constituent line of the polygon such that each point on each further generated line lies a distance corresponding to the shift distance from the closest point on the polygon.

The method may comprise iteratively repeating the roof feature generation process until no further polygons are generated , and all polygons have been degenerated to lines or points.

The method may comprise removing at least one and optionally all polygons and/or bisectors, which may be removed dependent on roof type.

The method may comprise determining a wall height and/or a roof height and/or a roof texture and/or roof type. The method may comprise determining a wall height and/or a roof height and/or a roof texture and/or roof type based on scale and/or shape of the footprint. The method may comprise determining a wall height and/or a roof height and/or a roof texture and/or roof height and/or roof type associated with other buildings, which may be determined to be in the vicinity of the building and determining the wall height and/or a roof height and/or a roof texture and/or roof type accordingly.

The method may comprise determining footprints from a plan or aerial view. The method may comprise determining a location, which may comprise a user's current location or an input location, which may be a user input location. The method may comprise retrieving and/or determining footprint data associated with the location . The method may com prise generati ng a field of view a round the determined or input location using the footprint data associated with the location. The field of view may comprise one or more 3D models. The method may be a method for operating an apparatus as set forth above in relation to the first aspect and/or a system as set forth in relation to the second aspect and/or a server as set forth in relation to the third aspect.

Features described above in relation to any of the first to third aspect may also be applicable to the fourth aspect.

According to a fifth aspect of the present invention is a computer program product and/or an apparatus programmed with a computer program product, the computer program product being adapted to implement an apparatus as set forth above in relation to the first aspect of the invention and/or a system as set forth above in relation to the second and/or third aspects of the invention and/or a method as set forth above in relation to the fourth aspect of the invention.

According to a sixth aspect of the invention is a method of determining roof meta data, comprising determining a scale and/or shape of a footprint, providing a database of typical footprint scale and/or shape data, matching the scale and/or shape of the footprint with the typical scale and/or footprint data and providing roof meta data associated with the matched scale and/or shape.

According to a seventh aspect of the invention is a method of determining roof meta data, comprising identifying at least one neighbouring building within a predefined distance of the roof, retrieving roof meta data associated with the neighbouring building and determining the roof meta data based on the roof meta data associated with the neighbouring building.

Although various features have been described in relation to specific aspects of the invention, it will be appreciated that features described in relation to one aspect of invention, or features analogous to those described features, may apply equally to any other aspect of the invention. For example, apparatus features may be applied to method features and vice versa.

Using the apparatus, systems, method and computer program products as defined above, it may be possible to reduce the amount of storage required to store 3D model information. Furthermore, in apparatus and systems that use communications over a communications network, the load placed on the communications network may be reduced and the time taken to communicate 3D model data may also be reduced. In addition, a system is provided that may be capable of generating a useful field of view image from 2D plan image data. Brief Description of the Drawings At least one embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic i ll ustration of an exemplary part of a Global Positioning System (GPS) usable by a navigation device;

Figure 2 is a schematic diagram of a communications system for communication between a navigation device and a server;

Figure 3 is a schematic illustration of electronic components of the navigation device of Figure 2 or any other suitable navigation device;

Figure 4 is a schematic diagram of an arrangement of mounting and/or docking a navigation device;

Figure 5 is a schematic representation of an architectural stack employed by the navigation device of Figure 3;

Figure 6 is a schematic illustration of entities supported by a processor of the navigation device of Figure 3;

Figures 7(a) to 7(c) are illustrations of examples of building formats representable by footprints;

Figure 8 is a schematic diagram of a footprint for use by the device of Figure

3;

Figure 9(a) is a schematic diagram of a footprint showing bisectors and intersections between bisectors generated from the footprint of Figure 8 by the device of Figure 3;

Figure 9(b) is a schematic diagram a footprint showing a polygons and lines generated from the footprint of Figure 8 by the device of Figure 3 during a first iteration;

Figure 9(c) is a schematic diagram of a footprint showing bisectors and lines generated from the footprint of Figure 8 by the device of Figure 3 during a second iteration;

Figures 10(a) to 10(d) shows schematic diagrams of examples of roof types; Figure 1 1 shows a diagram of a plan view image; and

Figure 12 shows a 3D model image generated using the device of Figure 3.

Detailed Description of Preferred Embodiments

Throughout the following description identical reference numerals will be used to identify like parts.

The mapping apparatus as described herein could cover any kind of image generation system that can map data to image features, for example image features of individual buildings, as well as apparatus that can produce images representative of navigable maps

Embodiments of the present invention will now be described with particular reference to a PND. It should be remembered, however, that the teachings of the present invention are not limited to PN Ds but are instead universally applicable to any type of processing device that is configured to execute navigation or mapping software so as to provide route plann i ng, navigation and/or mapping based functionality, or indeed any suitable viewing device or system for example any viewing device or system for viewing images of or associated with a structure. It follows therefore that in the context of the present application, a navigation device is intended to include (without limitation) any type of route planning, mapping and navigation device, irrespective of whether that device is embodied as a PN D, a vehicle such as an automobile, or indeed a computing resource, for example a portable personal computer (PC), a mobile telephone or a Personal Digital Assistant (PDA) executing viewing, mapping, route planning and/or navigation software.

It will also be apparent from the following that the teachings of the present invention even have utility in circumstances, where a user is not seeking instructions on how to navigate from one point to another, but merely wishes to be provided with a view of a given location. In such circumstances the "destination" location selected by the user need not have a corresponding start location from which the user wishes to start navigating, and as a consequence references herein to the "destination" location or indeed to a "destination" view should not be interpreted to mean that the generation of a route is essential, that travelling to the "destination" must occur, or indeed that the presence of a destination requires the designation of a corresponding start location.

With the above provisos in mind, the Global Positioning System (GPS) of Figure 1 and the like are used for a variety of purposes. In general, the GPS is a satellite-radio based navigation system capable of determining continuous position, velocity, time, and in some instances direction information for an unlimited number of users. Formerly known as NAVSTAR, the GPS incorporates a plurality of satellites which orbit the earth in extremely precise orbits. Based on these precise orbits, GPS satellites can relay their location to any number of receiving units.

The GPS system is implemented when a device, specially equipped to receive GPS data, begins scanning radio frequencies for GPS satellite signals. Upon receiving a radio signal from a GPS satellite, the device determines the precise location of that satellite via one of a plurality of different conventional methods. The device will continue scanning, in most instances, for signals until it has acquired at least three different satellite signals (noting that position is not normally, but can be d eterm i n ed , with on ly two sig na ls usi n g oth er trian gu lati on tech n iq u es). Implementing geometric triangulation, the receiver utilizes the three known positions to determine its own two-dimensional position relative to the satellites. This can be done in a known manner. Additionally, acquiring a fourth satellite signal allows the receiving device to calculate its three dimensional position by the same geometrical calculation in a known manner. The position and velocity data can be updated in real time on a continuous basis by an unlimited number of users.

As shown in Figure 1 , the GPS system 100 comprises a plurality of satellites 102 orbiting about the earth 104. A GPS receiver 106 receives spread spectrum GPS satellite data signals 108 from a number of the plurality of satellites 102. The spread spectrum data signals 108 are continuously transmitted from each satellite 102, the spread spectrum data signals 108 transmitted each comprise a data stream including information identifying a particular satellite 102 from which the data stream originates. The GPS receiver 106 generally requires spread spectrum data signals 1 08 from at least three satellites 1 02 in order to be able to calcu late a two- dimensional position. Receipt of a fourth spread spectrum data signal enables the GPS receiver 106 to calculate, using a known technique, a three-dimensional position.

Turning to Figure 2, a navigation device 200 comprising or coupled to the GPS receiver device 106, is capable of establishing a data session, if required, with network hardware of a "mobile" or telecommunications network via a mobile device (not shown), for example a mobile telephone, PDA, and/or any device with mobile telephone technology, in order to establish a digital connection, for example a digital connection via known Bluetooth technology. Thereafter, through its network service provider, the mobile device can establish a network connection (through the Internet for example) with a server 150. As such, a "mobile" network connection can be established between the navigation device 200 (which can be, and often times is, mobile as it travels alone and/or in a vehicle) and the server 150 to provide a "realtime" or at least very "up to date" gateway for information.

The establishing of the network connection between the mobile device (via a service provider) and another device such as the server 150, using the Internet for example, can be done in a known manner. In this respect, any number of appropriate data communications protocols can be employed, for example the TCP/IP layered protocol. Furthermore, the mobile device can utilize any number of communication standards such as CDMA2000, GSM, IEEE 802.1 1 a/b/c/g/n, etc.

Hence, it can be seen that the internet connection may be utilised, which can be achieved via data connection, via a mobile phone or mobile phone technology within the navigation device 200 for example.

Although not shown, the navigation device 200 may, of course, include its own mobile telephone technology within the navigation device 200 itself (including an antenna for example, or optionally using the internal antenna of the navigation device 200). The mobile phone technology within the navigation device 200 can include internal components, and/or can include an insertable card (e.g. Subscriber Identity Module (SIM) card), complete with necessary mobile phone technology and/or an antenna for example. As such, mobile phone technology within the navigation device 200 can similarly establish a network connection between the navigation device 200 and the server 150, via the Internet for example, in a manner similar to that of any mobile device.

For telephone settings, a Bluetooth enabled navigation device may be used to work correctly with the ever cha ngi ng spectru m of mobi le phone models , manufacturers, etc., model/manufacturer specific settings may be stored on the navigation device 200 for example. The data stored for this information can be updated.

In Figure 2, the navigation device 200 is depicted as being in communication with the server 1 50 via a generic commu n ications chan nel 1 52 that can be implemented by any of a number of different arrangements. The communication channel 152 generically represents the propagating medium or path that connects the navigation device 200 and the server 150. The server 150 and the navigation device 200 can communicate when a connection via the communications channel 152 is established between the server 150 and the navigation device 200 (noting that such a connection can be a data connection via a mobile device, a direct connection via personal computer via the internet, etc.).

The communication channel 152 is not limited to a particular communication technology. Additionally, the communication channel 152 is not limited to a single com m u n ication tech n ology; that is, the ch an n el 1 52 m ay i n cl ude several communication links that use a variety of technology. For example, the communication channel 152 can be adapted to provide a path for electrical, optical, and/or electromagnetic communications, etc. As such, the communication channel 152 includes, but is not limited to, one or a combination of the following: electric circuits, electrical conductors such as wires and coaxial cables, fibre optic cables, converters, radio-freq uency (RF) waves , the atmosphere, free space, etc. Furthermore, the communication channel 152 can include intermediate devices such as routers, repeaters, buffers, transmitters, and receivers, for example.

In one illustrative arrangement, the communication channel 152 includes telephone and computer networks. Furthermore, the communication channel 152 may be capable of accommodating wireless communication, for example, infrared communications, radio frequency communications, such as microwave frequency com m u n i cations , etc. Add itiona l ly, the com m u n ication cha n n el 1 52 ca n accommodate satellite communication.

The communication signals transmitted through the communication channel 152 include, but are not limited to, signals as may be required or desired for given communication technology. For example, the signals may be adapted to be used in cellular communication technology such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), etc. Both digital and analogue signals can be transmitted through the communication channel 152. These signals may be modulated, encrypted and/or compressed signals as may be desirable for the communication technology.

The server 150 includes, in addition to other components which may not be illustrated, a processor 154 operatively connected to a memory 156 and further operatively connected, via a wired or wireless connection 158, to a mass data storage device 160. The mass storage device 160 contains a store of navigation data and map information, and can again be a separate device from the server 150 or can be incorporated into the server 150. The processor 154 is further operatively connected to transmitter 162 and receiver 164, to transmit and receive information to and from navigation device 200 via communications channel 152. The signals sent and received may include data, communication, and/or other propagated signals. The transmitter 162 and receiver 164 may be selected or designed according to the com m u n ications req u i rem ent and com m u n ication tech n ology u sed i n the communication design for the navigation system 200. Further, it should be noted that the functions of transmitter 162 and receiver 164 may be combined into a single transceiver.

As mentioned above, the navigation device 200 can be arranged to communicate with the server 150 through communications channel 152, using transmitter 166 and receiver 168 to send and receive signals and/or data through the communications channel 152, noting that these devices can further be used to communicate with devices other than server 150. Further, the transmitter 166 and receiver 168 are selected or designed according to communication requirements and communication technology used in the communication design for the navigation device 200 and the functions of the transmitter 1 66 and receiver 1 68 may be combined into a single transceiver as described above in relation to Figure 2. Of course, the navigation device 200 comprises other hardware and/or functional parts, which will be described later herein in further detail.

Software stored in server memory 156 provides instructions for the processor 154 and allows the server 150 to provide services to the navigation device 200. One service provided by the server 150 involves processing requests from the navigation device 200 and transmitting navigation data from the mass data storage 160 to the navigation device 200. Another service that can be provided by the server 1 50 includes processing the navigation data using various algorithms for a desired application and sending the results of these calculations to the navigation device 200.

The server 150 constitutes a remote source of data accessible by the navigation device 200 via a wireless channel. The server 150 may include a network server located on a local area network (LAN), wide area network (WAN), virtual private network (VPN), etc.

The server 150 may include a personal computer such as a desktop or laptop computer, and the communication channel 152 may be a cable connected between the personal computer and the navigation device 200. Alternatively, a personal computer may be connected between the navigation device 200 and the server 150 to establish an internet connection between the server 150 and the navigation device 200.

The navigation device 200 may be provided with information from the server

150 via information downloads which may be periodically updated automatically or upon a user connecting the navigation device 200 to the server 150 and/or may be more dynamic upon a more constant or frequent connection being made between the server 150 and navigation device 200 via a wireless mobile connection device and TCP/IP connection for example. For many dynamic calculations, the processor 154 in the server 150 may be used to handle the bulk of processing needs, however, a processor (not shown in Figure 2) of the navigation device 200 can also handle much processing and calculation, oftentimes independent of a connection to a server 150.

Referring to Figure 3, it should be noted that the block diagram of the navigation device 200 is not inclusive of all components of the navigation device, but is only representative of many example components. The navigation device 200 is located within a housing (not shown). The navigation device 200 includes a processing resource comprising, for example, the processor 202 mentioned above, the processor 202 being coupled to an input device 204 and a display device, for example a display screen 206. Although reference is made here to the input device 204 in the singular, the skilled person should appreciate that the input device 204 represents any number of input devices, including a keyboard device, voice input device, touch panel and/or any other known input device utilised to input information. Likewise, the display screen 206 can include any type of display screen such as a Liquid Crystal Display (LCD), for example.

In one arrangement, one aspect of the input device 204, the touch panel, and the display screen 206 are integrated so as to provide an integrated input and display device, including a touchpad or touchscreen input 250 (Figure 4) to enable both input of information (via direct input, menu selection, etc.) and display of information through the touch panel screen so that a user need only touch a portion of the display screen 206 to select one of a plurality of display choices or to activate one of a plurality of virtual or "soft" buttons. In this respect, the processor 202 supports a Graphical User Interface (GU I) that operates in conjunction with the touchscreen.

In the navigation device 200, the processor 202 is operatively connected to and capable of receiving input information from input device 204 via a connection 210, and operatively connected to at least one of the display screen 206 and the output device 208, via respective output connections 212, to output information thereto. The navigation device 200 may include an output device 208, for example an audible output device (e.g. a loudspeaker). As the output device 208 can produce audible information for a user of the navigation device 200, it is should equally be understood that input device 204 can include a microphone and software for receiving input voice commands as well. Further, the navigation device 200 can also include any additional input device 204 and/or any additional output device, such as audio input/output devices for example. Th e p rocess or 202 i s o perative l y connected to memory 214 via connection 216 and is further adapted to receive/send information from/to input/output (I/O) ports 218 via connection 220, wherein the I/O port 218 is connectible to an I/O device 222 external to the navigation device 200. The external I/O device 222 may include, but is not limited to an external listening device, such as an earpiece for example. The connection to I/O device 222 can further be a wired or wireless connection to any other external device such as a car stereo unit for hands-free operation and/or for voice activated operation for example, for connection to an earpiece or headphones, and/or for connection to a mobile telephone for example, wherein the mobile telephone connection can be used to establish a data connection between the navigation device 200 and the Internet or any other network for example, and/or to establish a connection to a server via the Internet or some other network for example.

Figure 3 further illustrates an operative connection between the processor 202 and an antenna/receiver 224 via connection 226, wherein the antenna/receiver 224 can be a GPS antenna/receiver for example. It should be understood that the antenna and receiver designated by reference numeral 224 are combined schematically for illustration, but that the antenna and receiver may be separately located components, and that the antenna may be a GPS patch antenna or helical antenna for example.

It will, of course, be understood by one of ordinary skill in the art that the electronic components shown in Figure 3 are powered by one or more power sources (not shown) in a conventional manner. As will be understood by one of ordinary skill in the art, different configurations of the components shown in Figure 3 are contemplated . For example, the components shown in Figure 3 may be in communication with one another via wired and/or wireless connections and the like. Thus, the navigation device 200 described herein can be a portable or handheld navigation device 200.

In addition, the portable or handheld navigation device 200 of Figure 3 can be con nected or "docked" in a known manner to a vehicle such as a bicycle, a motorbike, a car or a boat for example. Such a navigation device 200 is then removable from the docked location for portable or handheld navigation use.

Referring to Figure 4, the navigation device 200 may be a unit that includes the integrated input and display device 206 and the other components of Figure 2 (including, but not limited to, the internal GPS receiver 224, the microprocessor 202, a power supply (not shown), memory systems 214, etc.).

The navigation device 200 may sit on an arm 252, which itself may be secured to a vehicle dashboard/window/etc. using a suction cup 254. This arm 252 is one example of a docking station to which the navigation device 200 can be docked. The navigation device 200 can be docked or otherwise connected to the arm 252 of the docking station by snap connecting the navigation device 200 to the arm 252 for example. The navigation device 200 may then be rotatable on the arm 252. To release the connection between the navigation device 200 and the docking station, a button (not shown) on the navigation device 200 may be pressed , for example. Other equally suitable arrangements for coupling and decoupling the navigation device 200 to a docking station are well known to persons of ordinary skill in the art.

Turning to Figure 5, the processor 202 and memory 214 cooperate to support a BIOS (Basic Input/Output System) 282 that functions as an interface between functional hardware components 280 of the navigation device 200 and the software executed by the device. The processor 202 then loads an operating system 284 from the memory 214, which provides an environment in which application software 286 (implementing some or all of the above described route planning and navigation functionality) can ru n . The application software 286 provides an operational environment including the GUI that supports core functions of the navigation device, for example map viewing, route planning, navigation functions and any other functions associated therewith. In this respect, part of the application software 286 comprises a view generation module 288.

Turning to Figure 6, the view generation module 288 supported by the processor 202 comprises a map data processor 290 capable of communicating with a view generation engine 292. The map data processor 290 is capable of accessing the memory 214 in order to access map data 293, the map data 293 comprising at least one footprint 294 and meta data including wall height data 296 and roof data 298, including roof type, height and texture meta data.

The view generation module 288 is operable to generate 3D models of buildings using the footprint 294 stored in the memory 214 and the metadata 296, 298.

The footprint 294 represents buildings having roofs of various forms, for example a building 300a having a four sided roof with a convex footprint, as shown in Figure 7(a), a building 300b having a four sided roof with a concave footprint, as shown in Figure 7(b), or a building 300c having a four sided roof with holes, for example representing a courtyard, as shown in Figure 7(c). The footprint data comprises an image or geometrical data that generally comprises or defines a series of component lines forming a polygon that is representative of an external perimeter, border or outline of a structure such as a building 300 when viewed from above, i.e. in plan view. An example of a suitable footprint 294 is shown in Figure 8.

The view generation module 288 is adapted to divide each footprint into segments, by matching the shape of the footprint to simple pre-defined shapes, such as rectangles and squares. The view generation module 288 is arranged to generate walls in 3 dimensions for each segment of the building 300 represented by the footprint 294 by generating a 3D object for each segment by extrapolating the perimeter of the footprint perpendicularly by a distance corresponding to the wall height obtained from the wall height data 296 stored in the memory 214. The walls of the building 300 are determined to correspond to the line of each segment that forms at least a portion of the perimeter of the building footprint 294.

The view generation module 288 is operable to generate a roof model for each building 300 from the footprint data 294 and the roof meta data 298. The view generation module 288 is operable to retrieve the roof type from the roof metadata 298 and perform a roof determination process based on the roof type.

Optionally, if any of the roof meta data 298 is not available from the memory 214, the processor 202 is operable to determine the roof meta data 298, for example, by associating scales and/or shapes of the foot print with typical metadata for that shape and/or scale and/or by determining roof type data for the roofs of other buildings in the vicinity of the building 300 for which the model is being determined.

The view generation module 288 is operable to identify a roof type from the roof meta data 298 and to generate a roof model in a manner that is dependent on the roof type. The operation of the view generation module 288 to generate a 4 sided roof for a concave footprint is described below. However, it will be appreciated that corresponding processes may be used to generate other roof types such as two sided roofs, pyramidal roofs and the like.

The map data processor 290 is operable to retrieve footprint data 294 and any roof meta data 296, 298 associated with a particular building from the memory 214 and communicate this to the view generation module 288.

The view generation module 288 processes the footprint 294 to identify any vertices 302 in the footprint, i.e. points associated with corners in the building 300 where the perimeter of the building 300 as indicated by the footprint 294 changes direction, as shown in Figure 9(a). For each vertex 302 of the footprint 294, the view generation module 288 calculates an associated bisector 304. Each bisector 304 takes the form of a line passing through the associated vertex 302 and extending internally of the footprint 294, wherein the angles between the bisector 304 and each of the sections of the footprint 294 that form the vertex 302 are equal.

Thereafter, the view generation module 288 is operable to determine any intersections 306 between bisectors 304. In this regard, for each bisector 304, only the closest intersection 306 to the vertex 302 associated with that bisector 304 is considered or determined. Furthermore, any intersections 306 lying outwith the footprint 298 are not considered or determined.

The view generation module 288 is then operable to determine the closest intersection 306a to the perimeter of the footprint 294 and calculate a shift amount 307 corresponding to the smallest distance between the closest intersection 306a and the perimeter of the footprint 294. The view generation module 288 is operable to generate a series of lines 308 corresponding to component lines that form the footprint, as shown in Figure 9(b). The generated lines 308 are generated by forming lines parallel to component lines 310 making up the footprint 294 and located internally of the footprint 294 by a distance corresponding to the shift amount 307. The generated lines 308 are sized such that the generated lines 308 approach no closer than the shift amount 307 to the footprint 294. It will be appreciated that, depending on the geometry of the footprint 294, these generated lines may form polygons 312, lines 314 or points.

If any polygons 312 are formed, then the view generation module 288 is operable to repeat the above processes with respect to each polygon 312, i .e. locating the vertices 312a of the polygon 312, calculating the bisectors 312b associated with each of the polygon's vertices 312a, calculating the intersections 312c of bisectors 312b and generating further polygons, lines 316 or points as appropriate based on the minimum distance between the polygon 312 and the closest intersection 312c, as shown in Figure 9(c). This process is repeated in an iterative fashion until no new polygons 312 are produced, and all the polygons 312 have been degenerated into lines 314, 316 or points. When no further polygons 312 can be produced, any polygons 312 that were generated are removed, leaving only the generated lines 314, 316, points (i.e. corresponding to roof apexes) and bisectors 304, 312b leading from an associated vertex 302 of the original footprint 294 to the first line 314, 316 or point it meets, which results in a final roof plan, as shown in Figure 9(d).

The relative height of each node, i.e. line 314, 316 or point, generated at each iteration is determined, and may be assigned an associated height based on a fraction of the maximum height retrieved from the roof meta data 298. For example, the highest nodes 316 (i.e. those generated in the final iteration) are assigned a relative height of 1 (corresponding to the height of the walls plus the maximum roof height) and the height at the vertices 302 of the original footprint 294 is assigned a relative height of zero (corresponding to the wall height). Nodes 314 generated in intervening iterations are assigned a relative height between 0 and 1 depending on which iteration it was generated at. In the case of bisectors 304, the relative height of each point on a bisector 304 is determined by extrapolating between the relative heights at each end of the bisector 304. The relative heights are used by the view generation module 288, along with roof height metadata 298, to scale the roof and determine the angle of the roof. Optionally, the total height of the roof can be determined based on the relative heights and type of roof (which can contain angle information).

The result of the roof data generation process performed by the view generation module 288 is to provide a series of segments, along with associated roof heights, angles and outline edges that may be used in conjunction with simple 3D objects representing the walls, in order to generate 3D models 320 of buildings 300, such as that shown in Figure 12.

It will be appreciated that this process may be modified for roof configurations other than a 4 sided concave roof. For example, in order to generate a two sided roof, as shown in Figure 10(a), bisectors corresponding to vertices of the building 300 having acute internal angles may be removed and any ends of generated lines 314', 316' that were located at a removed bisector may be extended to the perimeter of the footprint 294.

As an example of an application of the above process to pyramidal roofs, as shown in Figure 10(b), the bisectors 304" all meet at a single point 318 rather than a line 316, 318 or polygon 312.

Furthermore, the segmentation process used above to generate walls may also be used in relation to roofs. For example, the building 300 shown in Figures 10(c) and 10(d) has been segmented into two rectangular segments 319a, 319b, and each segment 319a, 319b treated as an independent footprint 294 to generate a four sided and two sided roof respectively. The view generation module 288 is operable to use one or more 3D building models 320 generated to create a field of view image, such as a field of view corresponding to the current location of the device, as determined using the GPS system 224, 226, or corresponding to a location input by a user using the input device 204. The 3D models 320 can be rotated, scaled, moved, and/or modified to account for perspective in accordance with their position relative to the determined or input location in order to create a field of view image.

In an optional embodiment, in additional or alternatively to storing footprints 294 of buildings 300 in the memory 214, the device 200 may be arranged to store aerial or plan view images 350, such as aerial or satellite photographs or town planning records, and to process the aerial or plan view images 350, for example as shown in Figure 1 1 , in order to determine building footprints 294, using techniques such as edge recognition, and pattern matching. The determined footprints 294 may be used in the same manner as stored footprints 294, as described above

By generating 3D models 320 from 2D footprints 294 in this way, the amount of d ata req u i red to be stored in the memory 214 and/or transmitted over a communications network may be minimised. As an illustration of this, a comparison of the data required to define a 3D model of the building illustrated in Figure 9(d) using data defining each vertex location in 3 dimensions is compared with the data required to generate the same 3D model based on a 2D footprint, according to embodiments of the present invention, as detailed in Table 1 below.

Table 1 : A comparison of the data requirements for defining a 3D building model using definitions of each vertex location vs using the footprint method for the model as shown in Figure 9(d)

As can be seen from Table 1 , in order to define the walls of the 3D building of Figure 9(d) in terms of the 3D coordinates of each vertex, the walls of the 3D model have 16 vertices, each vertex requiring three coordinates to define its 3D position, which requires enough memory to store 48 double precision floating point numbers. The roof in the 3D model has 12 vertices, each vertex requiring three coordinates to define its 3D location. This requires enough memory to store 36 double precision floating point numbers. Therefore, to store a 3D model of the building shown in Figure 9(d) in terms of the location of each of its vertices requires enough memory to store 84 floating point numbers. The complexity is also greatly increased , as 8 polygons (surfaces) are required to form the walls and 7 polygons (surfaces) are required to form the roof. Information relating to each polygon, such as which nodes are associated with which polygon, may also be stored. In this case, the memory required to store 3D models would also be increased.

I n contrast, it can be seen that the device 200 only needs to process 8 vertices defined in a 2D coordinate space in order to define the walls of the same building 300 plus an additional variable that defines the wall height. This only requires enough memory to store 17 double precision floating point numbers. Furthermore, only the two dimensional coordinates of 8 vertices 302, the height of the roof and the type of roof are required in order to generate a 3D roof image, which requ i res 1 7 dou ble precision floating poi nt n um bers and 1 integer n u m ber (representing the roof type). Therefore, only sufficient memory and bandwidth to store and transmit 34 floating point numbers and 1 integer number is required in order to display the 3D model 320 shown in Figure 9(d).

Even if the same location information is used to define common nodes between the roof and walls (i.e. the vertices where the roof and walls meet), then, for 3D models 19 nodes or 57 doubles are required and for the footprint method only 17 doubles and 1 "Integer are required.

As such, it will be appreciated that devices such as that described above that store and/or transmit 2D footprint data and associated metadata and are adapted to subsequently convert this into 3D model data, require considerably less memory and bandwidth to provide 3D model images than devices that directly store and transmit 3D model data.

A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the invention.

For example, although the above embodiments have been described in relation to a PND, it will be appreciated that the invention may be applicable to a much wider range of display and/or mapping and/or navigation applications. For example, the application may be used in relation to a display or mapping system running on a personal computer, laptop, PDA, mobile phone or other device with computational functionality, for example, akin to systems that provide applications such as Google (RTM) maps, Bing (RTM) maps, OVI (RTM) maps or the like.

Furthermore, it will be appreciated that the actual device performing the conversion from a 2D footprint image 294 and associated meta data 296, 298 to a 3D model 320 and any communications links required may vary. For example, the processing may optionally be performed on a portable device using 2D footprint and associated meta data stored in a memory 214 of the device. In this regard, the memory space on such devices is often limited and storing the source data in the form of footprint images and associated meta data and converting the footprint images into 3D model images using the metadata on the device may increase the amount of building models that can be stored on such devices.

In a further example, the image conversion/generation may be preformed on a computational device 200, such as those described above, and the footprint and associated metadata may be stored at a remote server 150 or database. In this case, communications bandwidth between the server/remote database and the computational device may be reduced, as the data transmitted is reduced and any storage of model data on the computational device may also be reduced.

Optionally, both the image data and processing may be performed at a remote location, such as a server 150, and transmitted to the device 200. This arrangement would result in more efficient use of storage 156 at the server 150 than storing the 3D model images directly.

Whilst embodiments described in the foregoing detailed description refer to

GPS, it should be noted that the navigation device may utilise any kind of position sensing technology as an alternative to (or indeed in addition to) GPS. For example the navigation device may utilise using other global navigation satellite systems such as the European Galileo system. Equally, it is not limited to satellite based but could readily function using ground based beacons or any other kind of system that enables the device to determine its geographic location.

Alternative embodiments of the invention can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, such as a diskette, CD-ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal being transmitted over a tangible medium or a wireless medium, for example, microwave or infrared. The series of computer instructions can constitute all or part of the functionality described above, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.

It will also be well understood by persons of ordinary skill in the art that whilst the preferred embodiment implements certain functionality by means of software, that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or indeed by a mix of hardware and software. As such, the scope of the present invention should not be interpreted as being limited only to being implemented in software.

Lastly, it should also be noted that whilst the accompanying claims set out particular combinations of features described herein, the scope of the present invention is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features or embodiments herein disclosed irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.

Claims

1. A navigation and/or mapping apparatus (200) comprising: a processing resource (202) operably coupled to a data store (214, 293), wherein the data store (214, 293) is adapted to store at least one footprint source and the processing resource (202) is adapted to obtain a footprint (294) from the footprint source, generate a model (320) of a structure based on the footprint (294) and provide image data relating to the model (320).

Apparatus according to Claim 1 , further comprising a display device (206) operably coupled to the processing resource (202), the processing resource (202) supporting, when in use, a view generation engine (292) and the display device (206) being arranged to receive the image data from the view generation engine (292) and display an image responsive to the image data.

A navigation and/or mapping apparatus (200) according to claim 1 or claim 2, wherein the footprint (294) defines a perimeter, outline or border of a building (300).

A navigation and/or mapping apparatus (200) according to any of the preceding claims, wherein the processing resource (202) is adapted to convert 2D footprint image data (294) into 3D model images (320).

A navigation and/or mapping apparatus (200) according to any of the preceding claims, wherein the processing resource (202) is adapted to determine a roof model using the footprint (294) and a stored or determined roof height.

A navigation and/or mapping apparatus (200) according to claim 5, wherein the processing resource (202) is adapted to determine vertices (302) of the footprint (294), determine a bisector (304) for at least one, and preferably each, vertex (302) of the footprint (294) and determine the roof model accordingly.

7. A navigation and/or mapping apparatus (200) according to claim 6, wherein the processing resource (202) is adapted to determine at least one intersection (306) between bisectors (304).

8. A navigation and/or mapping apparatus (200) according to claim 7, wherein the processing resource (202) is adapted to determine the closest intersection

(306a) or intersections to the footprint (294) and calculate a shift amount (307) corresponding to the distance between the closest intersection (306a) or intersections and the footprint (294).

9. A navigation and/or mapping apparatus (200) according to claim 8, wherein the processing resource (202) is adapted to generate lines (308) forming roof features, the generated lines (308) lying parallel to corresponding constituent lines of the footprint (294), and shifted toward the centre of the footprint (294) by an amount corresponding to the shift distance (307) from a corresponding constituent line of the footprint (294) such that each point on each generated line (308) lies a distance corresponding to the shift distance (307) from the footprint (294).

10. A navigation and/or mapping apparatus (200) according to claim 9, wherein the data store (214, 293) is adapted to store metadata (296, 298) related to the footprint (294) and/or the processing resource (202) is adapted to determine metadata (296, 298) related to the footprint.

1 1 . A navigation and/or mapping apparatus (200) according to claim 10, wherein the meta data (296, 298) comprises wall height and/or a roof height and/or texture information and/or a roof type data.

12. A navigation and/or mapping apparatus (200) according to claim 10 or claim 1 1 , wherein the processing resource (202) may be adapted to generate the model (320) using the footprint (294) and metadata (296, 298) related to the footprint (294).

13. A navigation and/or mapping apparatus (200) according to any of the preceding claims, comprising a location determination unit (224) operably coupled to the processing resource (202) and adapted to determine a location and/or a user input device (222) adapted to receive an input location, wherein the processing resource (202) is adapted to determine a model (320) of a building (300) associated with the determined or input location.

14. A navigation and/or mapping apparatus (200) accord ing to any of the preceding claims, wherein the navigation and/or mapping apparatus (200) comprises a portable navigation device.

15. A navigation and/or mapping system comprising: a navigation and/or mapping apparatus (200) according to any of claims 1 to 14; wherein the data store (160) and/or the display (206) is remotely located from the navigation and/or mapping apparatus (200) and accessible via a communications network (152).

16. A method for generating an image, the method comprising: obtaining at least one building footprint; determining a roof height; and generating a 3D roof model using the footprint and the roof height.

17. A computer program product and/or an apparatus programmed with a computer program product, the computer program product being adapted to implement an apparatus according to any of claims 1 to 14 and/or a system according to claim 15 and/or a method according to claim 16.