נראה שנפחי המידע/דרישות החומרה אינם גדולים במיוחד, אז הצעתי בתוקף לפחות בכל הקשור בעיבוד הלילי. לגבי שירות במהלך היום זו יותר שאלה של רוחב פס/מס' חיבורים במקביל כפי שאני מבין, אם תתנו לי הערכה יכול להיות שאוכל לאפשר גם את זה.
בכל מקרה עדכנו אותי בדרישות יותר ספציפיות, ואשמח לעזור. 2012/8/28 Yehuda Bar-Nir <[email protected]>: > אופס, > רק דיברתי על סדרי עדיפויות, ומסתבר שברשימת הדוור של הפרויקט אחד המפתחים > הראשיים הודיע על שיפור בקוד שהוא ביצע ועוזר להקטין את גודל הגרף המחושב ב 30% > (כפי שהוא נשמר על הדיסק). > https://groups.google.com/forum/m/#!topic/opentripplanner-dev/Z0tRCvPjQzU > > זה עדיין לא אומר מה יהיה גודל הזכרון הפיזי הנדרש בזמן העיבוד או בזמן ריצת > שרת הווב, אבל יש תקווה. אני אבדוק את הקוד החדש אחרי שיכנס ל github, ואדווח > כאן בימים הקרובים. > > יהודה > > ב-28 באוג 2012, בשעה 06:40, Yehuda Bar-Nir <[email protected]> כתב/ה: > > הבעיה (למיטב הבנתי) איננה מגבלה תאורית בתורת הגרפים או משהו כזה, אלא משהו > הרבה יותר פרקטי של ״מישהו צריך לכתוב את הקוד הזה״. קוד הבסיס של OTP משמש > מספר די גדול של מערכות תכנון תחבורה ציבורית, ורובן מגיעות לבעיות זכרון (אם > בתהליך החישוב או הריצה). הרבה מתלוננים על זה ברשימת התפוצה של OTP, והפתרון > של פיצול לאזורים הוא היחידי שמוצע כרגע. גם האפשרות לפצל את אזור הכיסוי > ולאפשר לשרת ווב אחד להחזיק בזכרון מספר גרפים אזוריים נכנסה ל upstream רק > בשבועות האחרונים, ועדיין לא ניסיתי אותה בעצמי. יכול להיות שהיא תקל על דרישות > הזכרון בשלב העיבוד הלילי, אבל דווקא תגדיל את דרישות הזכרון של שרת הווב. > צריך לזכור שהקוד של OTP הוא אמנם פתוח ונהנה מתרומת קוד מכל העולם, אבל הגרעין > של הפיתוח נעשה ע״י חברה (ללא מטרת רווח) שממומנת ע״י מספר תאגידי תחבורה > ציבורית חזקים בארה״ב (מניו-יורק, פורטלנד ואחרים) שמבחינתם קניית שרת של 32GB > הוא טיפה בים ההוצאות השוטפות. כשהם מגדירים את סדרי העדיפויות להמשך הפיתוח > אני מניח שהקטנת הזכרון נמצאת בעדיפות נמוכה יחסית לשיפור זמני תגובה, או ייעול > המסלול. > יהודה > > > > ב-28 באוג 2012, בשעה 02:43, Omer Zak <[email protected]> כתב/ה: > > On Mon, 2012-08-27 at 22:58 +0300, Yehuda Bar-Nir wrote: > > > <מבחינת אפשרויות של ביזור החישוב, הדרך היחדה שנראית לי אפשרית היא חלוקה > <אזורית, כלומר לחלק את קבצי ה GTFS וה OSM למחוזות (צפון, מרכז, דרום), > <או לערים (חיפה, ת"א, ירושלים, באר-שבע, ...) כך שלכל אזור יחושב גרף > <נפרד קטן הרבה יותר. החיסרון של ביזור כזה הוא שאחר-כך צריך להציג למשתמש > <מסך מקדים שמבקש ממנו לבחור את אזור הנסיעה המבוקש ורק בשלב השני להציג > <את המפה ואת טופס החיפוש. זה מונע לתכנן נסיעה מירושלים לחיפה למשל. > > נראה לי מוזר. היה אפשר לצפות שבמשך השנים מישהו חכם הספיק לפתח אלגוריתם > שמאפשר בניית גרפים לפי אזורים ואחר כך איחודם לגרף אחד גדול. > > אם אין אלגוריתם כזה, מי שיפתח אותו יוכל לזכות בפרסום אקדמי רב ו/או > תמלוגים נאים אם יצליח לרשום עליו פטנט. בטוחני שפרויקט ה-OTP הישראלי > אינו היחידי שיכול להפיק תועלת מאלגוריתם כזה. > > --- עומר > > -- > "Kosher" Cellphones (cellphones with blocked SMS, video and Internet) > are a menace to the deaf. They must be outlawed! > (See also: > http://www.zak.co.il/tddpirate/2006/04/21/the-grave-danger-to-the-deaf-from-kosher-cellphones/ > and > http://www.zak.co.il/tddpirate/2007/02/04/rabbi-eliashiv-declared-war-on-the-deaf/) > My own blog is at http://www.zak.co.il/tddpirate/ > > My opinions, as expressed in this E-mail message, are mine alone. > They do not represent the official policy of any organization with which > I may be affiliated in any way. > WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html > _______________________________________________ > Discussions mailing list > [email protected] > http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions > > > _______________________________________________ > Discussions mailing list > [email protected] > http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions _______________________________________________ Discussions mailing list [email protected] http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions
