Talk:Z-order curve

message: Neither nearby z-values are always nearby in multidimensions, nor vice versa. With Hilbert curve, nearby Hilbert values are always nearby in multidimensions (but not vice versa, of course). So the Hilbert curve is better locality preserving (for example), so "well" is not extraneous.  —Preceding unsigned comment added by Hermann.tropf (talk • contribs) 16:25, 26 July 2008 (UTC)
thread_title: "well reintrocuced"

message: I reintroduced the description of the 1966 Morton paper as it has given the curve its name and as it is very difficult to get (I had difficulties, I did even not get it from IBM directly). I tried it in a condensed manner, surely the description can be improved... --Hermann.tropf (talk) 16:42, 26 July 2008 (UTC)
thread_title: historical morton paper

message: I'm having trouble understanding the "Use with one-dimensional data structures for range searching" section.  It seems there should be a clear description of what the question is.  It is clear that the author intends to be doing an axes-aligned rectangle search, but it's not clear what the search is supposed to report, nor what the data structure is (the first sentence assumes the existence of one, but doesn't define it).  Finally, precisely what does locality preserving mean?  Bhudson (talk) 06:12, 9 March 2009 (UTC)
thread_title:  range searching 

message: Does locality-preserving help with compression? I tried to gzip a z-order encoded 3d voxel image but it created a bigger file than a simple gzipped byte[,,]. Pathbuiltnow (talk) 07:51, 3 January 2011 (UTC)
replies: text: I wouldn't expect locality-preserving to help compression, at least in the case of an image with many repeated identical patterns, since a translation by a few pixels of an image would significantly change the Z-order of the image data (same as a small translation of the Z-order data would mess up the image), but translation by a few pixels would completely preserve the "normal" order of the image data. Locality might be useful for compression, in the case that each "pixel" consisted of a lot of data, and nearby pixels consisted of similar data. Κσυπ Cyp   21:50, 12 March 2011 (UTC)
thread_title: Compression

message: Not sure how the python code in the article should work. What should be the input-format (bin or dec)?
So I write my own code to transfer a point to a position on z-curve:
def zorder(a, b):
  abin=str(bin(a)[2:].zfill(18))
  bbin=str(bin(b)[2:].zfill(18))
  print "abin: " + abin
  print "bbin: " + bbin
  y="0b"
  for k in range(18):
    y+=bbin[k] + abin[k]
  return int(y,2) 
zorder(2,3)
Result: 14
I hope this helps and perhaps somebode can include this to article. --Kolossos (talk) 22:10, 22 July 2011 (UTC)
thread_title:  python code 

message: The "Z-curve" is not a space-filling curve.  It is not a curve (as opposed to just a function) in any mathematical sense, because it is not continuous: the points .011111111...1 (finite number of 1's) and .1 are aribtrarily close together but get mapped to the points (.0111...1,.111...1) and (.1,.0), respectively, which are separated by a distance >.1111...1 (in the y-coordinate alone).  I aim to fix this in the article, but wanted to get any discussion out of the way here first. Wpegden (talk) 13:44, 4 April 2012 (UTC)
replies: text: Yes, something is wrong with the article. It is talking about a map from the plane to the line (ignoring for the moment if that map is well defined). A curve would be a map from the line to the plane. — Carl (CBM · talk) 16:59, 4 April 2012 (UTC)
replies: text: I don't think whether it's plane→line or line→plane matters so much because it's a bijection (ignoring the ambiguities in binary notation for numbers that end in repeating 1's vs repeating 0's). But as Wpegden says, a proper curve should be defined by a continuous function in the line→plane direction and this one is not continuous. —David Eppstein (talk) 21:08, 4 April 2012 (UTC)
replies: text: Yep. — Carl (CBM · talk) 23:33, 4 April 2012 (UTC)
thread_title:  this is NOT a space-filling curve! 

message: I think that the claims of "locality" should be qualified, since the limit is not continuous. A comparison to a Peano curve, in both directions (R \to R^2 and R^2 \to R) would clarify things. Bernardofpc (talk) 15:19, 11 February 2013 (UTC)
thread_title:  Locality 

message: What was the contribution of Lebesgue? Why is it also called the Lebesgue curve?
Surely Lebesgue must have first introduced this curve if it is named after him.
What did he say about the curve?  — Preceding unsigned comment added by 145.94.130.134 (talk) 13:47, 19 July 2018 (UTC)
thread_title:  Lebesgue 

message: There is no "international patent" recognition, because it is a public domain algorithm. Morton used it in in the 1960's and 1970's for information-retrieval  (today "database application"). 
About US-only "try to patent", Wikipedia is not a place to cite local-jurisdiction patent data. Even in US, there are no serious recognition, S2-geometry is free, is using Apache2 license since 2015. Krauss (talk) 22:51, 1 May 2021 (UTC)
thread_title:  Please remove patent advertising 

message: "Z" is like "2", when mirrored is like "5". This mirrored-Z is the most usual in maps, see Geohash.
Krauss (talk) 09:26, 6 September 2023 (UTC)
thread_title:  Mirrored-Z is also Z