• GPS, Cell Phones, and the .nyc TLD

last modified March 23, 2013 by tomlowenhaupt

How can a TLD serving New York City be imagined geographically? How will GPS/GIS technology as embedded in mobile devices such as cell phones improve city  life?  Here we explore the relationship between GPS, cell phones, and the .nyc TLD.

-------------------------------------------------------------------------------------------------------------------------------------------------

GPS Enabled Cell Phones

cell-phone.0.jpg

Names - Numbers - Maps - and People

It's frequently said that IPv6 numbers are virtually limitless. There are several interesting ways to view to view the number of internet names and addresses that will soon be be available under IPv6, here are three of of my favorites.

  • The Atomic View - Today’s Internet runs on IPv4 (Internet Protocol version 4) with 32-bits in each address, allowing about 4 billion address combinations. We are now in a transition to IPv6 (see IPv5 here) which will expand the address space to 128-bits. I’m told that’s enough address to provide a name for every atom in the planet’s surface - 340,282,366,920,938,463,463,374,607,431,768,
  • The Short and the Long of It - Here's another way to look at this huge 128-bit address space: i.e., 4.3 billion total IPv4 addresses versus 3.4 x 1038 total IPv6 addresses. If you imagine one IPv4 address being one picometer long (one trillionth of a meter), the entire IPv4 address space would be approximately 4.3 millimeters long – the length of an average sized ant. If each IPv6 address was one picometer long, the length of the entire IPv6 address space would be approximately 3.4 billion trillion trillion kilometers, or 36 billion light years. The farthest visible object in the universe from the Earth is estimated to be 30 billion light years away. (Based on data from the September 2006 CED Magazine. Sounds far out!)
  • The Small and the Big of It - Or think about IPv4 names fitting within a container the size of a cell phone and IPv6 fitting within one the size of the earth. (As told at ICANN L.A., October 2007.)
  • While all this makes it sound as if there is an adequate supply of addresses, it depends on how they are used. For example, that 36 billion light year length is one picometer wide. Double its width, to two picometers wide, and it's "only" 18 billion light years long. But make that width 53 kilometers, the distance from the southern tip of Staten Island to the top of the Bronx, and what is the distance that line goes out into space? Now, spread those names over the 30 kilometer width of the city, and what is the volume, i.e., how far out does it go? Here's the crazy math.

Let's simplify and transform IPv6's 340,282,366,920,938,463,463,374,607,431,

768,211,456 addresses / names into picometers. You get 340,000,000,000,000,000,000,000,000,000,

000,000,000 picometers, each representing one address / name.

53 kilometers = 53,000,000,000,000,000 picometers (or pmeter).

So 53... pmeters divided into 340... pmeters = 6,500,000,000,000,000,000,000 pmeters. That is, a north to south wall of IPv6 addresses one pmeter wide would be 6,500,000,000,000,000,000,000 pmeters high.

Now divide 6,500,000,000,000,000,000,000 pmeters by 30 kilometers (the city's width) or 30,000,000,000,000,000 pmeters and you get (30,000,000,000,000,000 into 6,500,000,000,000,000,000,000 = 30 / 6,500,000 =) 216,666 pmeters. That is, evenly spread out, and using a pmeter to represent an IP address, the city would be covered by 216,666 addresses /names per pmeter.


216,666 pmeters = 2.16666e-7 meter. My math notation fails me here. But if we compare 216,666 pmeters with the IPv4 ant (with 4 billion addresses), we have a very, very, very slim layer of names covering the city.

So much for the unlimited address space.

So What Do We Do?

Lets move a picometer back to reality. We don't need to track objects or locations to the picometer level. What size objects are we seeking to monitor? (Once again, contribute to the Privacy and GIS page.) By today's standard, the smallest RFID device measures 0.15 mm × 0.15 mm, and is thinner than a sheet of paper (7.5 micrometers). Factoring this out, if we were concerned with items minimally the size of RFIDs, the volume of our address space (the vertical of our city) would be ???, enough to make using IP numbers in a GIS system a practical consideration.(But the number are for machines, not space, so #fail.)

GPS and GIS in the World of IP Names & Addresses

A Few Preliminary Thoughts

Think of location as a permanent point on the earth. (Ignore our flying through the universe at 90k miles per second.)

Objects are mobile and move from point to point.

If you give every object an IP address and place an RFID-like device on it, and you assign an IP address to every location, you'll have the makings of a most detailed tracking system. (See Privacy and GIS.)

GIS indicates where things were, are, will, or could be located within a map framework.

GIS uses longitude and latitude and gets very specific.

What role is there for GIS in an era of mobility?

Proximity Services

Think of the model of Landing Lights Park on secondlife.com's Democracy Island. Or about Google Earth or Microsoft Live. What if this type of model was expanded to the entire city?

IP numbers deal with nodes (computer, printer, cell phone...) on the network. Each node is located at a longitude and latitude.

Each IP address has a number and each number can can have a name associated with that number. It's like your place of residence: it has an address and it can have a name associated with it. A name is not required for a house or a node.

IP numbers (see sidebar) can play a role in managing city resources via a close integration of GPS/GIS and the .nyc TLD.

Geographic Domain Names

There are four questions associated with geographic names:

  1. Where are official city maps found within the .nyc TLD: maps.gov.nyc? And what about names like maps.nyc, map.nyc, gis.nyc, and GISMO.nyc? Are these managed or auctioned or First Come First Served? (See the Domain Name Allocation Plan for more on this.)
  2. How are geographic names allocated within the .nyc TLD? The .berlin group has set aside 15,000 public areas (plazas, streets, neighborhoods) for individual development. They imagine it working as follows. Say you're trying to remember where you saw a particular item in a store. You were somewhere on 8th Street, but you're not sure where. Following the .berlin plan, you'd go to www.8thstreet.nyc and begin a search at a managed virtual street.
  3. What naming structure should we use for multi-word names. For example, is it JacksonHeights.nyc, Jackson-Heights.nyc, or Jackson_Heights.nyc? This is important to the intuitive operation of the TLD.
  4. We have domain names of geographic subdivisions: Boroughs: queens.nyc, manhattan.nyc, brooklyn.nyc vs. (kings.county.ny.us), bronx.nyc, staten-island.nyc. Neighborhoods: jackson-heights.nyc, astoria.nyc, greenwich-village.nyc, uppereastside.nyc, upper-east-side.nyc, bensonhurst.nyc. The borders of these are set socially and change by time and individual. Parks: central-park.nyc, centralpark.nyc, central_park.nyc, central-park.gov.nyc.

Street Furniture

There are practical uses of IP addresses, like in managing public spaces. What about assigning a IP address to every location? For example, we might assign each sign post, street light, bench, or statue an IP number and name. Next, imagine linking a name to a website. Now imagine someone sees a neglected (or loved) work of art in Prospect Park and wants to learn its provenance.

First thing they'll need to do is "connect" with the statue by locating it's website. They can do this be finding it's name etched on the statue, or, if its been obscured, locating it on a GIS service like OASIS. (If an object is unnamed, one might assign a name. This might have application outside the realm of street furniture.)

Next, one can connect to this website to learn about the statue. Or one might add info, wiki-style. If the romance continues, s/he might decide to help assure its upkeep by connecting with others similarly concerned, via the website.

Relationships of this sort can be built when creating a clean-slate .nyc TLD. It will empower public involvement with their management and maintenance.

Well, you might say, interesting idea, but there are a lot of locations. You'd need a lot of numbers. Are there enough resources - IP names and numbers - to achieve this?

Related Pages

Key .nyc Pages

Each of the 75+ pages on this wiki invites user contributions and is linked to one of the following key pages. (To edit the wiki you must join the project.)

  • The TLD Acquisition Campaign - The .nyc TLD's acquisition effort requires that we develop support here in New York City and convincingly present our goals and capabilities to the organization that issues new TLDs, the ICANN. Find out how you can help.
  • Advantages of the .nyc TLD - Marketing city resources, creating a more livable city, economic development, community awareness, Internet access and training, and more.
  • Mission & Objectives - Why we exist and what we hope to accomplish.
  • The Operating Environment - Issuing names, operating the registry, maintaining a directory, and creating a safe communications environment that benefits all New Yorkers is our key mission.
  • Domain Name Allocation Plan - Help decide which domain names will be set aside for public use, for operational purposes, for auction, or distributed on a as first come first served basis.
  • The Development Environment - Here we will explore personal, family, civic, community, and business networking applications that might help create a more livable city. Should security and privacy be our highest development priority? Where should education, training, and access be on our priority list? Help decide.
  • Governance - Like the air, water, streets and schools the .nyc TLD is commons and will serve residents best when operated transparently and with the public engaged in its governance.
  • FAQ - Frequently Asked Questions about the .nyc TLD are presented here.
  • Connecting.nyc Inc. Home Page
  • Our Blog