0:00
/
0:00

Maps and a way forward to AI

Our maps are changing, I wonder what Gerardus Mercator would say

This article and also its place in the Mitchells Rewrite was a draft by myself, that I shared with Google Gemini, to get feed back, I asked “Is this Possible “ simple answer was yes, and went on at length.

Then I asked my very good friend Jonathon Pickup to offer comment, he is helping me to Edit the book, but he is primarily the best person to talk to re Vectorwork.

After a long talk with Jon on Google workplace, which I might add is excellent, we finaly got the text into shape,

So this is not the final finished copy, but very near. Its ideal for adding to your knowledge base and expanding as you do your own research and experiments with AI

I like chatting with Gemini, exploring ideas and concepts, one of which is Maps, another topic, for another post, is how should we teach using AI, I suspect for many its a simple do this for me, but thats wrong, the AI will only spew out what it knows not understanding you or the subject, so having a conversation helps it to understand and for me, offer tips on subject and areas of interest.

I am now writing the initial articles in Google Docs, as Gemini can read these easily, where as Pi and Grok seen to have problems with txt, pages or word docs

So here is the almost finished article:

Maps in General

The current digital maps are a world away from the Mercator map produced by Gerardus Mercator, produced in 1569, it is a remarkable map that we can recognise the main continents.

So many maps were made by the many great explorers who painstakingly mapped the known world. Voyages that took years to map small portions of the planet can now be done in minutes, with a depth of clarity that is not just skin deep but layered and precise.

Digimap

Maps are important and can be looked at for general location and surrounding area

In chapter 19 this is taken to a higher level showing how maps are used in a more detailed way for site visits and underlying detail. Initially, maps are often for location and site location, orientating the North Point, general heights and general Sun Path analysis.

Contours

All paper and digital maps show the hight related to Newlyn in the UK or to a Datum. Contour show of the land as lines often coloured orange or light brown. The heights shown are referenced to a single spot in the UK that being Newlyn in Cornwall.

Heights of the central line of most roads are defined by the manhole covers to most major drainage system, and are linked to the invert level of the pipe directly below the manhole cover.

There is no central dataset of these levels, they are often controlled by the local water authority in the UK, or by the local authority, who will often release a

their levels by printed maps or by online GIS information.

This is important when designing buildings and how you will access the main foul and storm drains for your building.

Defining Boundaries

Many a dispute has its origins in poorly marked boundaries. One of the main tasks when drawing a site plan is to define the legal boundary. So what is a boundary, the simple answer is almost anything, from a path edge, Wall, fence, hedge, ditch, even brass studs set into a paved area. In some countries the boundary is marked by pegs in the ground.

Who owns the boundary is usually a “T” sign marked on the Land Registry map, sometimes with a notification as to maintenance responsibility.

Digital Data

Since the very early days whether we realised it or not, we relied on data in a paper based system. It was tedious and long winded, often badly maintained or not at all. In the digital computer age data is 100% digital, and often automatically generated and kept updated as CAD designs or GIS information on line.

As CAD develops, so does the use and influence of data. 2D has given way to 3D and the metaverse, giving rise to new technology, to view and interact with the building and its surrounds, using the vast repository of data available.

Often described as BIM, or Building Information Management, or modelling, it is a fast and ever changing landscape and should be one of your core CPD research areas.

Latitude & Longitude

We define a position on the earths surface for location buildings, ship and planes by the means of lines of latitude and longitude, running between the two poles, and bands running parallel to the equator.

You may remember a mention of Time being important in Chapter 4, the use of time in measuring distance travelled by sailors where each of the lines of Longitude represents a time position, ie 360 degrees divided by 24 hours, so each longitude degree line equals 15º of the earth

Knowing the difference between noon in London at the prime meridian or the start and end of the lines of longitude and noon at your present position allows you to easily calculate which line of longitude you are on. Measuring the angle of the sun at noon will tell you from tables which line of latitude you are on, and therefore your location on the planet.

This is fine for navigating from A to B, but because the lines of longitude are not parallel to each other, this is not used when setting out a building.

Eastings and Northings

In the UK, to overcome the problem of lines of longitude not being parallel, being an obvious problem in setting out a new building, Surveyors devised a square grid based upon the prime meridian to locate one long edge, which was used to set up a square grid across the whole of theUK. Lines parallel to the primary Meridian are called northern and Lines perpendicular to the primary Meridian are called eastings.

A separate grid was set up for Ireland. Set up on a line of Longitude specific to Ireland.

A square grid is by far the easiest method of controlling the setting out of any new building and calculating the digital reference point for each corner.

Although the Eastings and Northings grid method is the most widely used surveying tool used across the whole of the planet, Lat & long are also used to calculate specific locations to calculate the line of the sun at any given day and year.

Magnetic North, Grid North and Polar North

Defining north is often misunderstood by so many people. In the construction industry, the grid running almost parallel to the line of longitude is used to define north, the prime meridian. Magnetic north is never used as it's a constantly moving point controlled by the earth's internal magneto core The difference between true North and magnetic north is known as the magnetic north declination. Which is constantly changing.

It is possible to use magnetic North with a compassif you know the day's exact location of the magnetic north (MN declination) but this should never be used to build withMost Electronic compass found on mobile phones, point to True North or the Polar North.

Satellite Geospatial location

With the rapid development of computers in surveying and their influence in the development of levelling and location tools, great strides have been made in scanning, location and digitising surveys. Survey tools such as the Theodolite are now considered to be out of date, but can be used for approximate setting out.

The scans from the many satellites in orbit can combine to produce maps of astounding accuracy, with an almost unlimited array of data, from contours, the vegetation, the type of vegetation, water courses, power sources, rock depth, etc.

We will look at this in more detail later in the Advanced Book, but a simple scan might have a relatively low resolution say several hundred meters per pixel, producing little useful information. Cities might be easily recognised and major rivers seen, large forests, and large farm field patterns. One of the challenges with satellites is that there might becloud cover when the images are taken, obscuring the information require.,

A high level of detail, brings clarity to the map, with a resolution of less than 30 CM per pixel, at this level cars, and building can easily be identified, in some detail.

High level scans often have aditional information from Active SAR and LIDAR, to make cloud cover, and often leaves to trees invisible.

* SAR actively sends out radar pulses and measures the reflected signal. This allows it to penetrate clouds and operate day or night, revealing information about surface roughness, soil moisture, and even some subsurface features.

* LiDAR uses laser pulses to create highly accurate 3D models of the Earth's surface and objects on it, providing very precise elevation data and structural information.

Linking to AI

Linked to an AI as part of a graphical programming layer, the vast amount of linked data can create informaion that would take many hours to reproduce, and may well be out of date. A live link would enable combinations of Digital Twinn data from the building, compared to the satellite data, making Designs more robust and validated by real-time performance analysis and adherence to various constraints, leading to better-informed decisions from the earliest stages, through to live and even future events.

While there isn't a single, universally available "AI module" that directly plugs into Vectorworks Marionette, my CAD of Choice, right now in a ready-to-use package, the underlying technologies and methods for integrating AI with parametric design tools are definitely emerging and are very much possible.

It’s quite possible, AI could be (and in some cases, already is) linked to Marionette, moving from conceptual to more practical approaches:

Marionette's Python Foundation as the Bridge:The key enabler here is that Marionette is based on Python. Python is the de facto language for AI and machine learning. This means:

Direct Scripting (Advanced): A skilled user could write Python scripts within Marionette that leverage AI libraries (like TensorFlow, PyTorch, scikit-learn) for specific tasks. This would require significant programming knowledge and understanding of AI concepts. For example, you could write a Python node that:

Takes Marionette-generated geometry data.

Feeds it into a pre-trained machine learning model.

Receives optimized parameters or design suggestions back from the model.

Uses those suggestions to modify the Marionette network or generate new geometry.

External AI Integration: More commonly, AI functionality would likely reside in a separate application or cloud service, with Marionette acting as the communication hub.

I asked Google Gemini to look at a scrpit to use an API: this came back: Could the Marionette script that could call upon an external AI to do a lot of this

Yes, absolutely! The most practical and powerful way for Marionette to leverage external AI capabilities would be by calling upon external AI services or models. This is a common pattern in software development today, often referred to as using an "API" (Application Programming Interface).

Here's how a Marionette script could achieve this, and why it's such a viable approach:

The Mechanism: API Calls

Marionette's Python foundation is key here. Python has excellent libraries for making web requests (HTTP requests). AI models are frequently deployed as web services, meaning you can send data to them over the internet and receive results back.

Marionette Node (Python Script): You would create a custom Marionette node (or a series of nodes) that contains Python code.

Data Preparation: This Python code would take input from the rest of your Marionette network (e.g., geometry data, site information, user preferences). It would then format this data in a way that the external AI service expects (e.g., as a JSON object, an image file, or text).

API Request: The Python code would then make an HTTP request (like a POST request) to the external AI service's API endpoint. This request would include your prepared data.

Example Libraries: Python's requests library is a popular and easy-to-use library for making these HTTP requests.

AI Processing (External): The external AI service (running on a powerful server in the cloud, or even a local server you've set up) receives the data, processes it using its trained AI model, and generates a result.

Result Retrieval: The AI service sends its result back to Marionette's Python node as an HTTP response (again, often in JSON format).

Data Interpretation & Application: The Marionette Python node would then parse this result. It would take the AI's output (e.g., optimized dimensions, a list of suggested materials, a generated image, a refined layout) and convert it into data that can be used by other Marionette nodes to modify or create geometry, set parameters, or inform the design.

Why This Approach is Ideal:

Scalability & Performance: Training and running large AI models require significant computational resources. By using external services, Marionette doesn't need to run the heavy AI computations locally. The AI can leverage powerful cloud GPUs or dedicated servers, providing faster and more complex analysis.

Access to State-of-the-Art AI: You can tap into highly sophisticated, pre-trained AI models developed by companies like Google (e.g., Gemini API), OpenAI (ChatGPT, DALL-E), Stability AI, or specialized architectural AI firms. These models are constantly updated and improved.

Modularity: The AI model is decoupled from Vectorworks/Marionette. This means:

The AI model can be updated or even swapped out without needing to modify your Marionette network significantly, as long as the API interface remains consistent.

Different Marionette networks can leverage the same external AI service for various tasks.

Flexibility: You're not limited to what can be directly embedded in Vectorworks. You can connect to almost any AI model that exposes a web API.

Easier Development (for architects): While creating the API call node still requires Python knowledge, you don't need to be an AI/ML expert to use the AI. You just need to understand how to send data to and receive data from the API. The complex AI training and model management are handled by the external service provider.

Real-World Scenarios (How it would look):

Generative Layouts:

Marionette defines site boundary and program areas.

Python node sends this data to an external AI service specialized in architectural layouts (e.g., a service trained on thousands of floor plans and circulation patterns).

AI generates several optimized layout options (e.g., as nested polygons or room labels).

Python node receives options and feeds them back into Marionette to generate actual walls, doors, and furniture.

Facade Optimization:

Marionette creates a base building massing.

Python node sends geometry and environmental data (sun path, orientation) to an external AI trained on facade performance.

AI suggests optimal window-to-wall ratios, shading device designs, or material choices based on daylighting/energy goals.

Python node returns parameters, and Marionette applies them to the facade.

Material Selection & Costing:

Marionette generates a building model with generic material assignments.

Python node sends building component data (e.g., wall area, roof type) to an external AI connected to a material database and current pricing.

AI suggests cost-effective or sustainable material alternatives and provides a preliminary cost estimate.

Python node updates material data in the Marionette object properties.

AI Visualizer:

Marionette generates a simple 3D model.

Python node takes a screenshot or exports basic geometry and sends it to an external image-to-image AI (like Stable Diffusion or Midjourney through an API).

AI generates stylized architectural renders based on text prompts and the input image.

The generated image is returned and could be displayed in Vectorworks or saved.

This distributed approach, where Marionette orchestrates the design logic and communicates with specialized external AI brains, is undoubtedly the most promising and powerful path for integrating advanced AI into architectural design workflows.

Discussion about this video

User's avatar