— Log opened Thu Oct 13 13:01:49 2005
13:02 stvn: log's started
13:05 Cappelaere: was looking at Openstreetmaps...
13:09 Cappelaere: HUmmmm.... they ar elooking at SVG/AJAX rendering in Firefox...
13:10 CameronS: Yes, I understand they already have an applet as well.
13:13 CameronS: Looks like Mike won't be with us.
13:13 CameronS: Lets start.
13:13 stvn: k
13:13 CameronS: Steven, do you want to talk about MapPane?
13:13 Cappelaere: k
13:14 stvn: k
13:15 stvn: the new mappane does some magic I can't really follow, but the end result is wrong
13:16 CameronS: Do you know who created the magic?
13:16 stvn: for each layer it changes the url, but it doesn't alter the widget in which the image is
13:16 stvn: either mike or michael or a combination of both
13:17 stvn: radim also commented on mappane
13:17 CameronS: Yes.
13:18 CameronS: Maybe the problem was introduce by the DragPan functionality.
13:18 stvn: I'm afraid that mappane isn't transparent enough anymore and is not a good example how to apply the MVC approch in mapbuilder
13:18 stvn: I believe so, but I think it is possible to keep the dragpan functionality
13:19 stvn: the problem is in mappane altering the layer-url without taking into account the entire layer-widget
13:19 CameronS: Are you saying the the HTML doesn't reflect the state in the Context (WMC) model?
13:19 stvn: yep
13:19 CameronS: Ah, sounds like that needs to be fixed.
13:19 stvn: yep, but I'm not up to it I'm afraid
13:20 CameronS: And I agree, we should fix it before release 1.0
13:20 Cappelaere: what does Mike say about this?
13:21 stvn: not much yet, I've reported to him, but he hasn't had time to respond yet
13:21 CameronS: Yes, we probably should wait for Mike's response before we move forward.
13:21 stvn: true
13:21 CameronS: I was hoping he would be able to comment today.
13:21 * stvn too
13:22 CameronS: Shall we defer this till Mike responses and move on.
13:22 CameronS: ?
13:22 Cappelaere: agree
13:22 stvn: ok, sidenote: mappane also brakes fixPNG(), which radim pointed out
13:23 CameronS: Steven, thanks for bringing the issue up.
13:23 Cappelaere: I guess this is pri 6
13:23 CameronS: yes or 7.
13:23 Cappelaere: yep
13:23 stvn: it's 6 now, i can move it up one notch
13:24 CameronS: 6 is fine for the moment. We aim to fix all pri 6 issues.
13:24 CameronS: Pat, you thought any further about icons/
13:24 CameronS: ?
13:25 Cappelaere: I am still thinking about those
13:25 Cappelaere: several issues
13:26 Cappelaere: 1. we need to support mnay icons and have good looking ones
13:26 Cappelaere: we need to enroll icon factories to help
13:26 Cappelaere: it has to be easy for the users
13:26 Cappelaere: SLD route is intriguing but does not appear easy to me
13:27 CameronS: I think if we start from the icon route first, we have a broken design.
13:27 Cappelaere: we should have an icon palette that can hold many different stencils
13:27 Cappelaere: user-driven
13:27 stvn: how do you mean stencilS?
13:27 CameronS: We should be first creating a list of iconTypes first, then the user selects an iconType.
13:27 Cappelaere: and allow different user communities to select their icon sets and draw their own maps
13:28 CameronS: Pat is talking about icons to drag onto a map (as a feature).
13:28 stvn: k
13:28 CameronS: Steven, you familiar with the SLD spec?
13:28 Cappelaere: that list is infinite
13:28 stvn: Cappelaere: not really
13:28 Cappelaere: ?
13:29 Cappelaere: can you explain?
13:29 stvn: s/Cappelaere /CameronS
13:29 CameronS: 
13:29 stvn: happens with tab completion and nicks that both start with ca 
13:30 Cappelaere: so i can imagine thousand of icon sets
13:30 CameronS: For a particular application we need to convert click points to GML in a WFS.
13:31 CameronS: Each click point/icon needs to have an associated layer/attribute value in the GML.
13:31 CameronS: And we need to define the GML structure up front so that we can have a structured database at the back end.
13:32 Cappelaere: that's what Galdos has been trying to do
13:32 Cappelaere: tooooooo complex
13:32 Cappelaere: you get into a huge GML schema mess
13:32 Cappelaere: our users cannot manage this
13:32 Cappelaere: I could not
13:32 Cappelaere: then I went to geoserver
13:33 Cappelaere: in 2 minutes, I had a table working
13:33 Cappelaere: no GML
13:33 Cappelaere: and I could extract data
13:33 Cappelaere: and display it on the map
13:33 CameronS: From where I stand GML=Table in a database.
13:33 CameronS: But I see your point about making it easy for users.
13:34 Cappelaere: ther eis a big difference between starting with a GML schema and a SQL database
13:34 stvn: Cappelaere: if we implement a proper GML based solution, the users don't have to worry about GML I guess
13:34 Cappelaere: creating a GML schema is a PITA
13:34 CameronS: Are you suggesting that each icon references a UrL to an icon. Attribute=icon uRL (or similar reference)?
13:34 Cappelaere: Problem is that every implementation is different
13:35 Cappelaere: I would imagine that every community might be building its own feature layer of things of interest
13:35 Cappelaere: so they create a SQL table (easy) and add it to GEoServer
13:36 Cappelaere: then then select an icon (or many icon sets) to add to the palette
13:36 CameronS: So each community has their own set of icons? (Say 100 or 1000 icons per community?)
13:36 Cappelaere: absolutely
13:36 Cappelaere: DOD with 2525B
13:36 Cappelaere: US Coast Guard
13:37 Cappelaere: Emergency Reponders
13:37 Cappelaere: GreenMaps
13:37 CameronS: Ok, so lets say that we call the mapping between icon and icon title a SLD document.
13:37 CameronS: The SLD is just a mapping between a name and an icon.
13:37 Cappelaere: may be
13:37 CameronS: Each layer on a Map could use it's own SLD if need be.
13:38 Cappelaere: I am coming from a differnt angle with geoRSS
13:38 Cappelaere: data is not necessarily in a WFS
13:38 Cappelaere: it could but not necessarily
13:39 Cappelaere: so styling might not happen on the WFS side
13:39 Cappelaere: look at GeoRSS renderer
13:39 CameronS: ok
13:39 Cappelaere: it takes geoRSS files and renders on the map
13:39 Cappelaere: it easily parses the files and makes the association
13:40 Cappelaere: that's easy to understand and maintain
13:40 CameronS: How is the association between GeoRSS term and icon maintained?
13:40 Cappelaere: that is the same trade Radim was talking about XSLT/XML vs js
13:41 Cappelaere: user defined
13:41 Cappelaere: in js
13:41 CameronS: In effect, it would be a table?
13:42 Cappelaere: yes
13:42 CameronS: The table could be stored in JS, or it could be stored as XML?
13:42 Cappelaere: yes
13:43 stvn: I've just been reading up on the SLD spec, it doesn't seem overly complex
13:43 CameronS: And if it is stored as XML, they we may as well use a format that is already defined - like SLD.
13:43 stvn: http://www.opengeospatial.org/docs/02-070.pdf page 54 has an example XML on how to store a image
13:44 Cappelaere: so on the client side, the user has to now write a another stylesheet to render his feed on the map
13:45 Cappelaere: and we are back in that mess
13:45 CameronS: That would be one way to implement it.
13:45 Cappelaere: I am trying for a simpler solution
13:45 Cappelaere: there might not be one
13:46 Cappelaere: anyways....
13:46 Cappelaere: what about having our own Tango team?
13:46 Cappelaere: we need to enroll some graphic designers
13:46 Cappelaere: we need to update the web site
13:46 CameronS: I'd suggest that we will eventually need a SLD parser because some layers will have them and will want to render their data according to the SLD.
13:47 Cappelaere: I have to unfortunately agree with that statement
13:47 Cappelaere: I am just trying to avoid to require our users to write a SLD
13:47 Cappelaere: unless we auto-generate it
13:48 CameronS: exactly.
13:48 stvn: auto-generation is a pre
13:48 Cappelaere: problem is that the icon sets are usually disconnected from the data they end up representing
13:48 CameronS: We create a SLD model which has addIcon(icon, description)
13:48 Cappelaere: So we would require an icon factory to write an XML file to describe the icon sets
13:48 CameronS: Inside addIcon() we call setXpath()
13:49 Cappelaere: then we would need another mapping between the icon set and the data set
13:49 CameronS: I think you will find it fairly easy to impliment.
13:49 Cappelaere: this gets complex real quick
13:49 Cappelaere: which part?
13:50 Cappelaere: then the user decides that it is really cool to add a red triangle on the map
13:50 CameronS: I think the SLD model will be as simple as a getIcon(description) and setIcon(icon, description)
13:50 Cappelaere: oops can't do that now
13:51 Cappelaere: what about if you would not need it at all
13:51 Cappelaere: you store an Symbol Identification Code with the object
13:52 Cappelaere: and it gets rendered automatically
13:52 Cappelaere: all icons would be required to get a unique uuid
13:52 stvn: Cappelaere: but you still need to store somewhere what the actual image is
13:53 Cappelaere: that would be handled somehow by the Icon Manager on the client side
13:53 stvn: it's not much different from CameronS proposal with get/setIcon
13:53 Cappelaere: depending on what the user decides to use
13:53 Cappelaere: like fonts on a computer
13:54 CameronS: Ok, Let's rename SLDModel.js to IconManager.js and I think the problem stays the same.
13:54 Cappelaere: you send me a document and I can render it differently
13:55 Cappelaere: I was interested in the Tango naming convention but could not get to it
13:55 Cappelaere: MIL 2525B has that concept
13:55 CameronS: So IconManager stores a table matching SymbolIds to Icons?
13:55 Cappelaere: not really
13:56 CameronS: Got a URL handy?
13:56 Cappelaere: I sent it to you a while back .... hold on
13:56 Cappelaere: http://symbology.disa.mil/symbol/mil-std.html
13:57 Cappelaere: the IconMgr gets a directory name that contains many subdirs with various icon sets
13:57 Cappelaere: and can buil its table at runtime
13:57 Cappelaere: so it knows what the user has in the toolbox
13:57 Cappelaere: like fonts
13:58 Cappelaere: you can drop icon sets in that directory
13:58 Cappelaere: or switch to another directory based on your skin
13:58 Cappelaere: when the user drops an icon on the map, its uuid comes with it
13:59 Cappelaere: the user can then annotate the entry with a form based on the table she has defined for that feature
13:59 Cappelaere: then we do a WFS insert
13:59 Cappelaere: no SLD
14:00 Cappelaere: no GL schemas
14:00 Cappelaere: GML
14:00 Cappelaere: if we use MySQL GeoServer
14:00 stvn: (tango is up n running again BTW)
14:00 Cappelaere: cool
14:00 CameronS: So we select a base skin directory (equivalent to a SLD doc)
14:01 Cappelaere: I do not have the full solution yet but I am still thinking out loud
14:01 Cappelaere: I want to make it easy for the users
14:01 CameronS: The skin directory contains a mapping (dirName -: icon) similar to SLD matching iconName -: icon
14:01 Cappelaere: VISIO does not require you to write a SLD to add a stencil on your diagram
14:02 stvn: Cappelaere: the trouble of this solution is that it's dependant on geoserver/mysql, which makes mapbuilder less flexible in use
14:02 Cappelaere: not really
14:02 Cappelaere: the mere presence of that directory does the matching
14:02 stvn: ah ok
14:02 Cappelaere: and the files in it which have the right name
14:02 Cappelaere: back to naming
14:03 CameronS: Pat, is your problem that SLD is too complex rather than the fact that you don't think it will work?
14:03 Cappelaere: I am sure it will work (because it already does)
14:03 Cappelaere: it is too complex for our users
14:03 stvn: Cappelaere: still it wqould be possible that a user drops an icon in mapbuilder, this is recognised as a new icon and a SLD doc is generated
14:04 Cappelaere: yes but why?
14:04 stvn: I agree that we should shield the users from writing SLDs
14:04 Cappelaere: now you need to cynchronize the SLDs of every user in the community
14:04 stvn: Cappelaere: mainly because once we got SLD working we can use other SLD'd iconsets
14:04 Cappelaere: like which one?
14:05 stvn: er.. the to-be-developed-ones
14:05 Cappelaere: there is an infinite set.
14:05 Cappelaere: that's the problem
14:05 Cappelaere: like fonts
14:06 Cappelaere: look at the symbol fonts
14:06 Cappelaere: I an use any of those in my document
14:06 stvn: I might be mistaken, but if an iconset is available in SLD form, you can just pick out of them just like you can use any WMS server which is available?
14:06 Cappelaere: wait
14:07 Cappelaere: let's pick an icon set made of colored triangles, squares and circles
14:07 stvn: this would make it much easier for us, since we don't need to update the iconsets in the mapbuilder release and it keeps the download much smaller
14:07 CameronS: I'm going to have to go.
14:07 Cappelaere: 2 different sets are available from 2 vendors
14:07 Cappelaere: user picks one
14:07 stvn: bye CameronS
14:07 CameronS: Are we still right to meet same time next week?
14:07 Cappelaere: and decides that a red triangle means a trash can
14:08 Cappelaere: then who does the SLD
14:08 Cappelaere: sure
14:08 Cappelaere: bye
14:08 stvn: CameronS: yep
14:08 CameronS: bye - I'll leave myself logged on for a while.
14:09 stvn: BTW we have featurefreeze today
14:09 stvn: Cappelaere: ah i see the prolem
14:10 Cappelaere: It gets tricky very fast
14:10 Cappelaere: and could be a lot of work
14:10 stvn: Cappelaere: I'm not too versed in SLD, but i assume that you can set <pointsymboliser*: to define how the icon looks like, where to get it etc
14:11 stvn: and somewhere else to what the pointsymboliser should be attached to (for instance trash can)
14:11 stvn: the tango project on the other hand decides for you how a trashcan looks like
14:11 Cappelaere: not sure exactly to be honest
14:12 stvn: you cannot say that a trashcan looks like a triangle, unless you break the iconset
14:12 Cappelaere: I think that Tango associates a name for a trashcan icon. If you use anoter skin, it still works
14:12 stvn: (or create a new iconset)
14:12 stvn: yep
14:13 Cappelaere: I would like to be able to drop a new icon in a directory and start using it right away
14:14 Cappelaere: I would only need to follow a name convention of some sort
14:14 stvn: I like to be able to drop an icon in the browser and use it straight away, since i don't have access to the directory
14:15 Cappelaere: user in that context is the cartographer
14:15 stvn: ah ok
14:16 Cappelaere: the admin guy that integrates the system
14:16 Cappelaere: in my case, I have to keep adding symbols for new data coming in
14:16 stvn: maybe in that case it is easier to use your approach, but to rename an entire iconset is also a PITA
14:18 Cappelaere: true
14:18 Cappelaere: but if we use the names as the key, then any name would work
14:19 stvn: I was thinking about an online way, than it might be easier to use SLDs, for setup a naming scheme should do the trick as well
14:19 Cappelaere: as long as they are no conflict (back to fonts again)
14:20 stvn: the problem is that there's an unlimited amount of icons (unlike characters in a font)
14:20 Cappelaere: a SLD ties the icon to the featureType and this is on the user side.
14:20 stvn: so the naming scheme has to account for that
14:20 Cappelaere: there is an unlimited font sets
14:20 Cappelaere: no difference
14:21 stvn: Cappelaere: yep, but in a fontset there's only 256 characters
14:21 Cappelaere: icon = character
14:21 stvn: and in an iconset there can be more than 256 icons
14:21 Cappelaere: many people do use truetype fonts for symbols
14:21 Cappelaere: we might want to go back to that concept
14:21 stvn: Cappelaere: still there are only 256 symbels in the font, hence the 5 fontsets esri gives you
14:22 Cappelaere: ESRI does support many user-defined symbol sets
14:22 stvn: my point is that a font has a very fixed naming scheme: bit 0 to bit 255, so it's easy to create/parse
14:23 Cappelaere: and?
14:23 stvn: the iconset has a unlimited amount of names in the set and an unlimited amount of icons
14:23 stvn: so it's more difficult to parse
14:24 Cappelaere: in reality, there are hardly more than 256 symbols in a given set
14:24 Cappelaere: you have to break it down
14:24 stvn: what happens if someone creates a new icon that doesn't fit in the current naming scheme: he needs to come up with a new name; so how does mapbuilder know that new name?
14:25 Cappelaere: if you create a new icon, it has to be part of a set and has to have a name (or a uuid)
14:25 Cappelaere: MapBuilder should not care
14:25 stvn: ok
14:25 Cappelaere: it carries that set name/icon name around
14:26 Cappelaere: May be we should use the truetype standard
14:26 Cappelaere: Font Type/Char name
14:26 Cappelaere: for any icon
14:26 stvn: brr, that's ugly TBH
14:27 Cappelaere: This is what those guys did: http://www.fgdc.gov/HSWG/ref_pages/Incidents_ref.htm
14:28 stvn: it might be useful for a desktop application, since it makes it easier to insert symbols
14:28 Cappelaere: how different is it from our application?
14:29 stvn: we don't use
14:29 stvn: t
14:29 Cappelaere: we want to make it easy too
14:29 stvn: we don't use 't' to insert the wild fire symbol
14:29 stvn: we drag it to the map
14:29 Cappelaere: no but the computer does
14:29 Cappelaere: you drag an fire icon to the map, true
14:29 stvn: the computer doesn't care
14:30 stvn: the problem with truetype sets is that it's much more difficult to add a new icon
14:30 Cappelaere: that icon is represented by a Font Name and a character name -*: key
14:30 stvn: then with a directory of images
14:30 Cappelaere: the key is carried within the document
14:30 Cappelaere: it is rendered on the client side
14:30 Cappelaere: we can use the same concept
14:31 Cappelaere: dir name + icon name -*: key
14:31 Cappelaere: like incident.K
14:31 Cappelaere: which makes it easy to retrieve
14:32 Cappelaere: and get the icon back
14:32 stvn: hm i'm still not convinced, but maybe it works
14:33 Cappelaere: I am not either
14:33 Cappelaere:
14:33 Cappelaere: I just feel that forcing users to write a SLD is a non starter
14:33 stvn: that I agree
14:33 stvn: hence the SLD-generator
14:34 Cappelaere: why do we need it again?
14:34 stvn: hehe
14:34 Cappelaere: you need to carry a feature type in that table anyway
14:34 stvn: the main reason is; it's a standard to do what we want to do
14:34 Cappelaere: that feature type could be anything
14:35 Cappelaere: it is user driven
14:35 stvn: i've to go, brb
14:35 Cappelaere: so that feature type for that particular incident could be incident.K
14:35 Cappelaere: ok
14:45 ! Cappelaere [n=Patrice@pcp0011331517pcs.elictc01.md.comcast.net] has quit ["Quit"]
— Log closed Thu Oct 13 15:01:50 2005
Page Operations
Browse Space